[Bug go/106747] New: Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 Bug ID: 106747 Summary: Regression: go version does not print a number in 12.x Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- If my observations are correct, in the 11.x series go version printed a version number, while in the 12.x series it prints: $ go version go version unknown linux/amd64 The unknown-version is printed on git commit a3bd980b9b146633e2 ( Daily bump. 20220814) In the 11.x series it printed $ go version go version go1.16.5 gccgo (GCC) 11.2.1 20211010 linux/amd64 This is a regression.
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/106744] [13 Regression] phiopt miscompiles min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106744 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-08-26 Summary|phiopt miscompiles min/max |[13 Regression] phiopt ||miscompiles min/max Ever confirmed|0 |1 Priority|P3 |P1 Keywords||needs-bisection, wrong-code Target Milestone|--- |13.0 CC||tnfchris at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. CCing suspect.
[Bug debug/106746] New: [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 Bug ID: 106746 Summary: [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: compare-debug-failure Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: aoliva at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 53511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53511&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fsched2-use-superblocks -fcompare-debug testcase.c -save-temps -Wno-psabi x86_64-pc-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure (length) $ diff -u *gkd --- a-testcase.c.gkd2022-08-26 07:38:56.088210543 +0200 +++ a-testcase.gk.c.gkd 2022-08-26 07:38:56.131543638 +0200 @@ -435,11 +435,6 @@ ]) "testcase.c":24:5# {*andsi_1_zext} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) -(insn # 0 0 2 (set (reg:V16QI 23 xmm3 [272]) -(plus:V16QI (reg:V16QI 23 xmm3 [280]) -(mem/c:V16QI (plus:DI (reg/f:DI 7 sp) -(const_int -120 [0xff88])) [ S16 A128]))) "testcase.c":25:14# {*addv16qi3} - (nil)) (insn:TI # 0 0 2 (set (reg:V4SI 22 xmm2 [208]) (vec_concat:V4SI (reg:V2SI 22 xmm2 [224]) (reg:V2SI 26 xmm6 [221]))) "testcase.c":24:5# {*vec_concatv4si} @@ -493,12 +488,6 @@ (const_int 8 [0x8])) [ VIEW_CONVERT_EXPR(D.)[_45]+0 S4 A32])) "testcase.c":24:5# {*movsi_internal} (expr_list:REG_DEAD (reg:DI 1 dx [234]) (nil))) -(insn # 0 0 2 (set (reg:SI 2 cx [256]) -(mem:SI (plus:DI (reg/f:DI 7 sp) -(const_int 128 [0x80])) [ S4 A64])) "testcase.c":24:5# {*movsi_internal} - (expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 19 frame) -(const_int -200 [0xff38])) [ S4 A64]) -(nil))) (insn:TI # 0 0 2 (set (reg:V2SI 26 xmm6 [241]) (vec_concat:V2SI (reg:SI 26 xmm6 [241]) (reg:SI 22 xmm2 [orig:242 VIEW_CONVERT_EXPR(D.)[_51] ] [242]))) "testcase.c":24:5# {*vec_concatv2si} @@ -511,6 +500,33 @@ ... Renaming the variable "foo0_v512u32_0" to "b" makes the failure disappear. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-2206-20220825175413-g60d84e82639-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-2206-20220825175413-g60d84e82639-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220825 (experimental) (GCC)
[Bug c/106745] New: segfault in bpf_core_get_sou_member_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106745 Bug ID: 106745 Summary: segfault in bpf_core_get_sou_member_index Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- Created attachment 53510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53510&action=edit bug report output Running into this on master with the following patch(seems unrelated to the crash): https://patchwork.ozlabs.org/project/gcc/patch/87a681d7tf.fsf...@oracle.com/
[Bug tree-optimization/106744] New: phiopt miscompiles min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106744 Bug ID: 106744 Summary: phiopt miscompiles min/max Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kristerw at gcc dot gnu.org Target Milestone: --- GCC miscompiles the following test at -O1 or higher optimization levels: #include __attribute__((noinline)) uint8_t three_minmax1 (uint8_t xc, uint8_t xm, uint8_t xy) { uint8_t xk; if (xc > xm) { xk = (uint8_t) (xc < xy ? xc : xy); } else { xk = (uint8_t) (xm < xy ? xm : xy); } return xk; } int main (void) { volatile uint8_t xy = 255; volatile uint8_t xm = 0; volatile uint8_t xc = 255; if (three_minmax1 (xc, xm, xy) != 255) __builtin_abort (); return 0; } What is happening is that phiopt transforms three_minmax1 to _7 = MAX_EXPR ; _9 = MIN_EXPR <_7, xm_3(D)>; return _9; instead of the intended _7 = MAX_EXPR ; _9 = MIN_EXPR <_7, xy_4(D)>; return _9;
[Bug target/106742] ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in expand_vec_perm_broadcast_1, at config/i386/i386-expand.cc:21870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106742 --- Comment #1 from Hongtao.liu --- Should be caused by r13-2111-g6910cad55ffc33.
[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704 --- Comment #11 from Hongtao.liu --- Fixed in GCC12.3 and GCC13.
[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:9f78e7eb8e064556adf466444197aae8e52a1eb3 commit r12-8715-g9f78e7eb8e064556adf466444197aae8e52a1eb3 Author: liuhongt Date: Mon Aug 22 10:41:16 2022 +0800 Don't gimple fold ymm-version vblendvpd/vblendvps/vpblendvb w/o TARGET_AVX2 Since 256-bit vector integer comparison is under TARGET_AVX2, and gimple folding for vblendvpd/vblendvps/vpblendvb relies on that. Restrict gimple fold condition to TARGET_AVX2. gcc/ChangeLog: PR target/106704 * config/i386/i386-builtin.def (BDESC): Add CODE_FOR_avx_blendvpd256/CODE_FOR_avx_blendvps256 to corresponding builtins. * config/i386/i386.cc (ix86_gimple_fold_builtin): Don't fold IX86_BUILTIN_PBLENDVB256, IX86_BUILTIN_BLENDVPS256, IX86_BUILTIN_BLENDVPD256 w/o TARGET_AVX2. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106704.c: New test.
[Bug target/106704] [12/13 Regression] avx intrinsic not generating vblendvps instruction with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704 --- Comment #9 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:388f1a8cf0851854cc4d2ee99ed85600f0822afc commit r13-2208-g388f1a8cf0851854cc4d2ee99ed85600f0822afc Author: liuhongt Date: Mon Aug 22 10:41:16 2022 +0800 Don't gimple fold ymm-version vblendvpd/vblendvps/vpblendvb w/o TARGET_AVX2 Since 256-bit vector integer comparison is under TARGET_AVX2, and gimple folding for vblendvpd/vblendvps/vpblendvb relies on that. Restrict gimple fold condition to TARGET_AVX2. gcc/ChangeLog: PR target/106704 * config/i386/i386-builtin.def (BDESC): Add CODE_FOR_avx_blendvpd256/CODE_FOR_avx_blendvps256 to corresponding builtins. * config/i386/i386.cc (ix86_gimple_fold_builtin): Don't fold IX86_BUILTIN_PBLENDVB256, IX86_BUILTIN_BLENDVPS256, IX86_BUILTIN_BLENDVPD256 w/o TARGET_AVX2. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106704.c: New test.
[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #8 from Andrew Pinski --- So this is not a GCC bug, report it to binutils. though as I mentioned I think it was part of https://sourceware.org/bugzilla/show_bug.cgi?id=25713 which is causing the issue.
[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > (In reply to Andrew Pinski from comment #6) > > (In reply to Paul Hua from comment #5) > > > > > > Yes, we should do. This also fails the ABS_EXPR scan-tree-dump on > > > LoongArch. > > > > And on riscv32. I will look into that failure later this week. > > I am suspecting it is because for both LoongArch and RISCV, > logical-op-non-short-circuit defualts to 0. I am going to debug it right now. Oh I see the issue. it is not related at all to logical-op-non-short-circuit but rather than the testcase should be split into two, one for the scalar and one for the vector case. And then the vector case should match not at optimized but right before vector lowering happens, maybe in forwprop1 or 2.
[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > (In reply to Paul Hua from comment #5) > > > > Yes, we should do. This also fails the ABS_EXPR scan-tree-dump on LoongArch. > > And on riscv32. I will look into that failure later this week. I am suspecting it is because for both LoongArch and RISCV, logical-op-non-short-circuit defualts to 0. I am going to debug it right now.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #29 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #28) > With the following, I get the expected result. > Indeed, with se->want_pointer set, gfc_conv_expr generates an address > expression, so it has to be dereferenced to get back the variable. > > diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc > index 6c8fa16e723..367ecc2eb65 100644 > --- a/gcc/fortran/trans-expr.cc > +++ b/gcc/fortran/trans-expr.cc > @@ -9602,7 +9602,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, > bool add_clobber) > tree var; > /* FIXME: This fails if var is passed by reference, see PR > 41453. */ > - var = expr->symtree->n.sym->backend_decl; > + var = build_fold_indirect_ref_loc (input_location, se->expr); > clobber = build_clobber (TREE_TYPE (var)); > gfc_add_modify (&se->pre, var, clobber); > } I tried the more hackish @@ -9529,9 +9540,12 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, bool add_clobber) { tree clobber; tree var; + gfc_symbol *sym = expr->symtree->n.sym; /* FIXME: This fails if var is passed by reference, see PR 41453. */ var = expr->symtree->n.sym->backend_decl; + if (sym->attr.function && sym->result == sym) + var = gfc_get_fake_result_decl (sym, 0); clobber = build_clobber (TREE_TYPE (var)); gfc_add_modify (&se->pre, var, clobber); } but if your patch regtests fine then you should proceed.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #28 from Mikael Morin --- (In reply to anlauf from comment #23) > > No, they're not, when the procedures are in the same file. > At least that's what gdb tells me... gdb tells me the same. :-) It is a side effect of calling gfc_check_externals it seems. (In reply to anlauf from comment #27) > (In reply to Mikael Morin from comment #26) > > > > Upon return from gfc_conv_expr, se->expr holds the value of the expression. > > So basically var = se->expr; > > As we manage to pass __result_derfc as argument, then I expect se->expr to > > have value __result_derfc at that point. > > I tried that - just rechecked - and get an ICE: gimplification failed. > So there's some magic missing I don't see... With se->expr, what is generated is: &__result_derfc = {CLOBBER}; Not too bad, but not exactly there yet. With the following, I get the expected result. Indeed, with se->want_pointer set, gfc_conv_expr generates an address expression, so it has to be dereferenced to get back the variable. diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index 6c8fa16e723..367ecc2eb65 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -9602,7 +9602,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, bool add_clobber) tree var; /* FIXME: This fails if var is passed by reference, see PR 41453. */ - var = expr->symtree->n.sym->backend_decl; + var = build_fold_indirect_ref_loc (input_location, se->expr); clobber = build_clobber (TREE_TYPE (var)); gfc_add_modify (&se->pre, var, clobber); }
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #27 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #26) > (In reply to anlauf from comment #25) > > (In reply to Mikael Morin from comment #24) > > > (In reply to anlauf from comment #22) > > > > > > > > The remaining problem from PR41453#c8 is the following code in > > > > trans-expr.cc: > > > > > > > > (gdb) l 9539,9548 > > > > 9539 else if (add_clobber && expr->ref == NULL) > > > > 9540{ > > > > 9541 tree clobber; > > > > 9542 tree var; > > > > 9543 /* FIXME: This fails if var is passed by reference, > > > > see PR > > > > 9544 41453. */ > > > > 9545 var = expr->symtree->n.sym->backend_decl; > > > > 9546 clobber = build_clobber (TREE_TYPE (var)); > > > > 9547 gfc_add_modify (&se->pre, var, clobber); > > > > 9548} > > > > > > > > One needs to understand how to fix up 'var' here for the case at hand. > > > > > > > I guess the obvious one (se->expr) doesn’t work? > > > > Could you explain how to use it? (I don't have the necessary vision.) > > Upon return from gfc_conv_expr, se->expr holds the value of the expression. > So basically var = se->expr; > As we manage to pass __result_derfc as argument, then I expect se->expr to > have value __result_derfc at that point. I tried that - just rechecked - and get an ICE: gimplification failed. So there's some magic missing I don't see...
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #26 from Mikael Morin --- (In reply to anlauf from comment #25) > (In reply to Mikael Morin from comment #24) > > (In reply to anlauf from comment #22) > > > > > > The remaining problem from PR41453#c8 is the following code in > > > trans-expr.cc: > > > > > > (gdb) l 9539,9548 > > > 9539 else if (add_clobber && expr->ref == NULL) > > > 9540{ > > > 9541 tree clobber; > > > 9542 tree var; > > > 9543 /* FIXME: This fails if var is passed by reference, see > > > PR > > > 9544 41453. */ > > > 9545 var = expr->symtree->n.sym->backend_decl; > > > 9546 clobber = build_clobber (TREE_TYPE (var)); > > > 9547 gfc_add_modify (&se->pre, var, clobber); > > > 9548} > > > > > > One needs to understand how to fix up 'var' here for the case at hand. > > > > > I guess the obvious one (se->expr) doesn’t work? > > Could you explain how to use it? (I don't have the necessary vision.) Upon return from gfc_conv_expr, se->expr holds the value of the expression. So basically var = se->expr; As we manage to pass __result_derfc as argument, then I expect se->expr to have value __result_derfc at that point.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #25 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #24) > (In reply to anlauf from comment #22) > > > > The remaining problem from PR41453#c8 is the following code in > > trans-expr.cc: > > > > (gdb) l 9539,9548 > > 9539 else if (add_clobber && expr->ref == NULL) > > 9540{ > > 9541 tree clobber; > > 9542 tree var; > > 9543 /* FIXME: This fails if var is passed by reference, see PR > > 9544 41453. */ > > 9545 var = expr->symtree->n.sym->backend_decl; > > 9546 clobber = build_clobber (TREE_TYPE (var)); > > 9547 gfc_add_modify (&se->pre, var, clobber); > > 9548} > > > > One needs to understand how to fix up 'var' here for the case at hand. > > > I guess the obvious one (se->expr) doesn’t work? Could you explain how to use it? (I don't have the necessary vision.)
[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832 --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > This is intentional, if you embed an aggregate with flex array into another > struct and ask not to cross the field boundaries (i.e. bos1), then the size > of that field is exactly what is the maximum size. don't quite understand here: why "embedding an aggregate with flex array member into another struct" is asking not to cross the field boundaries? could you please explain a little bit on this?
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #24 from Mikael Morin --- (In reply to anlauf from comment #22) > > The remaining problem from PR41453#c8 is the following code in trans-expr.cc: > > (gdb) l 9539,9548 > 9539 else if (add_clobber && expr->ref == NULL) > 9540{ > 9541 tree clobber; > 9542 tree var; > 9543 /* FIXME: This fails if var is passed by reference, see PR > 9544 41453. */ > 9545 var = expr->symtree->n.sym->backend_decl; > 9546 clobber = build_clobber (TREE_TYPE (var)); > 9547 gfc_add_modify (&se->pre, var, clobber); > 9548} > > One needs to understand how to fix up 'var' here for the case at hand. > I guess the obvious one (se->expr) doesn’t work?
[Bug fortran/41453] use INTENT(out) for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |fortran --- Comment #9 from anlauf at gcc dot gnu.org --- Changing component to fortran.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #21) > (In reply to anlauf from comment #18) > > Tentative patch, regtests cleanly but otherwise untested: > > > > diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc > > index 850007fd2e1..0a1520e95ba 100644 > > --- a/gcc/fortran/trans-expr.cc > > +++ b/gcc/fortran/trans-expr.cc > > @@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * > > sym, > > else > > { > > bool add_clobber; > > - add_clobber = fsym && fsym->attr.intent == INTENT_OUT > > - && !fsym->attr.allocatable && !fsym->attr.pointer > > + gfc_symbol *dsym = fsym; > > + gfc_dummy_arg *dummy; > > + > > + /* Use associated dummy as fallback for formal > > +argument if there is no explicit interface. */ > > (...) > > Note that if there is no explicit interface, I expect associated_dummy to be > NULL, and as a result dsym and fsym to always actually be the same thing. No, they're not, when the procedures are in the same file. At least that's what gdb tells me...
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #22 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #20) > With your patch I still see > > __attribute__((fn spec (". r "))) > real(kind=8) derfc (real(kind=8) & restrict x) > { > integer(kind=4) jint; > real(kind=8) __result_derfc; > > derfc = {CLOBBER}; > calerf_r8 ((real(kind=8) *) x, &__result_derfc, &jint); > return __result_derfc; > > > I think the patch wouldn't adjust what the clobber is added to but only > whether it is added, but it seems it fails to catch this case? So maybe > the error is elsewhere. It appears that there are two (only weakly dependent) issues at play here: 1) The patch in comment#18 addresses only the case when the procedures are outside of a module, so that the frontend does not see their interfaces. But since we nowadays have a more global view of all procedures in a file, we are in principle able to exploit things like attributes of the dummies. 2) For the handling of clobber for variables that are associated with INTENT(OUT) dummy arguments see also PR41453, which is still open due to some corner cases not yet addressed. The present case, where the actual argument is the function result, shows an anomaly: The clobber is fine if the function has an explicit result clause, while we are confusing symbols (x vs. __result_x) when there is no result clause. See PR41453#c8 for details. The remaining problem from PR41453#c8 is the following code in trans-expr.cc: (gdb) l 9539,9548 9539 else if (add_clobber && expr->ref == NULL) 9540{ 9541 tree clobber; 9542 tree var; 9543 /* FIXME: This fails if var is passed by reference, see PR 9544 41453. */ 9545 var = expr->symtree->n.sym->backend_decl; 9546 clobber = build_clobber (TREE_TYPE (var)); 9547 gfc_add_modify (&se->pre, var, clobber); 9548} One needs to understand how to fix up 'var' here for the case at hand. > Note with my testcase from comment#11 fixed as you suggest I don't see a > clobber > at all - I probably simplified too much and gfortran needs the wrapped module > to see the intent(out). I thought to have fixed that one...
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #21 from Mikael Morin --- (In reply to anlauf from comment #18) > Tentative patch, regtests cleanly but otherwise untested: > > diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc > index 850007fd2e1..0a1520e95ba 100644 > --- a/gcc/fortran/trans-expr.cc > +++ b/gcc/fortran/trans-expr.cc > @@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * > sym, > else > { > bool add_clobber; > - add_clobber = fsym && fsym->attr.intent == INTENT_OUT > - && !fsym->attr.allocatable && !fsym->attr.pointer > + gfc_symbol *dsym = fsym; > + gfc_dummy_arg *dummy; > + > + /* Use associated dummy as fallback for formal > +argument if there is no explicit interface. */ > (...) Note that if there is no explicit interface, I expect associated_dummy to be NULL, and as a result dsym and fsym to always actually be the same thing.
[Bug target/106743] Illegal assembly code with -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106743 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- The inline-asm is wrong. It should be: __asm__("xchgb %b0, %h0 ## %0 " : "=Q"(__tmp) : "0"(__tmp)); q Any register accessible as rl. In 32-bit mode, a, b, c, and d; in 64-bit mode, any integer register. Q Any register accessible as rh: a, b, c, and d. Because you are accessing it as rh so you need to Q rather than q.
[Bug target/106743] Illegal assembly code with -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106743 --- Comment #1 from Andrew Pinski --- xchgb %bpl, %bp
[Bug middle-end/41453] use INTENT(out) for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #8 from anlauf at gcc dot gnu.org --- Sometimes we now generate a clobber for the wrong variable when a function result is involved. An example, derived from PR105012: ! compile with -fdump-tree-original module m contains SUBROUTINE Y (Z) real, intent(out) :: Z Z = 1. END SUBROUTINE Y FUNCTION X () real :: X CALL Y (X) ! direct use of function result, bad clobber END FUNCTION X FUNCTION F () result(res) real :: res CALL Y (res)! using explicit result variable, good clobber END FUNCTION F end With current trunk this produces: __attribute__((fn spec (". "))) real(kind=4) f () { real(kind=4) res; res = {CLOBBER}; y (&res); return res; } __attribute__((fn spec (". "))) real(kind=4) x () { real(kind=4) __result_x; x = {CLOBBER}; y (&__result_x); return __result_x; } __attribute__((fn spec (". w "))) void y (real(kind=4) & restrict z) { *z = 1.0e+0; } For function X (without the result clause) we should have: __result_x = {CLOBBER}; instead. We probably need to have a closer look here: (gdb) l 9539,9548 9539 else if (add_clobber && expr->ref == NULL) 9540{ 9541 tree clobber; 9542 tree var; 9543 /* FIXME: This fails if var is passed by reference, see PR 9544 41453. */ 9545 var = expr->symtree->n.sym->backend_decl; 9546 clobber = build_clobber (TREE_TYPE (var)); 9547 gfc_add_modify (&se->pre, var, clobber); 9548}
[Bug c++/106743] New: Illegal assembly code with -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106743 Bug ID: 106743 Summary: Illegal assembly code with -march=skylake Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stayprivate at gmail dot com Target Milestone: --- #include #include #define swapw(__val) \ ({ \ uint16_t __tmp = __val; \ __asm__("xchgb %b0, %h0" : "=q"(__tmp) : "0"(__tmp)); \ __tmp; \ }) int main() { int value = rand(); int a = swapw(value); std::cout << std::hex << "First value is " << value << " " << a << '\n'; } Compile with gcc (gcc 12 on Ubuntu ), and also with trunk. As shown on https://godbolt.org/z/oGn9WK6GE the assembler will generate the following error: : register type mismatch for `xchg' This is only when using -march=skylake or above and using -O1 or above. The code works in gcc-9/10/11.
[Bug middle-end/106738] -Wlarger-than triggering for *.LASAN0 section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106738 --- Comment #2 from Andrew Pinski --- Maybe DECL_IGNORED_P or DECL_ARTIFICIAL should be checked before calling warning in stor-layout.cc? Because: in asan.cc: ASM_GENERATE_INTERNAL_LABEL (buf, "LASAN", 0); var = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier (buf), type); TREE_STATIC (var) = 1; TREE_PUBLIC (var) = 0; DECL_ARTIFICIAL (var) = 1; DECL_IGNORED_P (var) = 1; ... in stor-layout.cc before doing the warning call: /* If requested, warn about definitions of large data objects. */ if ((code == PARM_DECL || (code == VAR_DECL && !DECL_NONLOCAL_FRAME (decl))) && !DECL_EXTERNAL (decl))
[Bug analyzer/106741] suspicious %qE related warning when building gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741 --- Comment #2 from Andrew Pinski --- /* If we haven't already defined a front-end-specific diagnostics style, use the generic one. */ #ifdef GCC_DIAG_STYLE #define GCC_PPDIAG_STYLE GCC_DIAG_STYLE #else #define GCC_PPDIAG_STYLE __gcc_diag__ #endif /* This header may be included before diagnostics-core.h, hence the duplicate definitions to allow for GCC-specific formats. */ #if GCC_VERSION >= 3005 #define ATTRIBUTE_GCC_PPDIAG(m, n) __attribute__ ((__format__ (GCC_PPDIAG_STYLE, m ,n))) ATTRIBUTE_NONNULL(m) #else #define ATTRIBUTE_GCC_PPDIAG(m, n) ATTRIBUTE_NONNULL(m) #endif extern void pp_printf (pretty_printer *, const char *, ...) ATTRIBUTE_GCC_PPDIAG(2,3); %qE support was added for GCC 8, with r8-499-631238ac3f50 . So if you are compiling with GCC 7 (or before), the first stage will warn about an unknown conversion type character ‘E’ but the 2nd and 3rd stages won't.
[Bug analyzer/106741] suspicious %qE related warning when building gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-08-25 --- Comment #1 from Andrew Pinski --- Is this during stage 1 or a latter stage? What GCC did you start with?
[Bug c++/106647] [C++23] P2362 - Remove non-encodable wide character literals and multicharacter wide character literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106647 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-08-25 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 53509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53509&action=edit gcc13-pr106647.patch Untested implementation.
[Bug middle-end/106725] LTO semantics for __attribute__((leaf))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725 --- Comment #4 from Daniel Thornburgh --- (In reply to rguent...@suse.de from comment #3) > As said, GCC shouldn't assume this since leaf is defined at translation > unit level, not at LTO level. Sure, but what prevents GCC from making this assumption? Are all uses of leaf evaluated before the TUs are merged? Does GCC have some provenance tracking for which TU a given function came from in the merged view? Is there a pass I missed to drop leaf after merging but before it's used?
[Bug target/106742] New: ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in expand_vec_perm_broadcast_1, at config/i386/i386-expand.cc:21870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106742 Bug ID: 106742 Summary: ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in expand_vec_perm_broadcast_1, at config/i386/i386-expand.cc:21870 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu 1. gcc 13.0.0 20220821 snapshot (g:d6a39c25c05c6ed5df8ce49eda719d17e40e29bb) ICEs when compiling the following testcase, reduced from gcc/testsuite/gcc.target/i386/vect-bfloat16-2a.c, w/ -O1: typedef __bf16 v8bf __attribute__ ((__vector_size__ (16))); v8bf vec_init_dup_v8bf (__bf16 a1) { return __extension__ (v8bf) { a1, a1, a1, a1, a1, a1, a1, a1 }; } % x86_64-unknown-linux-gnu-gcc-13.0.0 -O1 -c miuyjavi.c during RTL pass: expand miuyjavi.c: In function 'vec_init_dup_v8bf': miuyjavi.c:6:10: internal compiler error: in gen_lowpart_general, at rtlhooks.cc:57 6 | return __extension__ (v8bf) { a1, a1, a1, a1, a1, a1, a1, a1 }; | ^ 0x72fbae gen_lowpart_general(machine_mode, rtx_def*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/rtlhooks.cc:57 0x136df8b ix86_expand_vector_init_duplicate(bool, machine_mode, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/i386-expand.cc:15044 0x1371b6b ix86_expand_vector_init(bool, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/i386-expand.cc:16090 0x1a3c5ad ??? /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/sse.md:26600 0xb347a8 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/recog.h:407 0xb347a8 store_constructor(tree_node*, rtx_def*, int, poly_int<1u, long>, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:7407 0xb3760d expand_constructor /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:8745 0xb23daa expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:10990 0xb24d66 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:10629 0x9f0bac expand_expr /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.h:310 0x9f0bac expand_return /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:3809 0x9f0bac expand_gimple_stmt_1 /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:3918 0x9f0bac expand_gimple_stmt /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:4044 0x9f67b7 expand_gimple_basic_block /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:6096 0x9f8357 execute /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:6822 2. W/ -O0, it yields the following instead: % x86_64-unknown-linux-gnu-gcc-13.0.0 -O0 -c miuyjavi.c during RTL pass: expand miuyjavi.c: In function 'vec_init_dup_v8bf': miuyjavi.c:6:10: internal compiler error: in expand_vec_perm_broadcast_1, at config/i386/i386-expand.cc:21870 6 | return __extension__ (v8bf) { a1, a1, a1, a1, a1, a1, a1, a1 }; | ^ 0x7d0713 expand_vec_perm_broadcast_1 /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/i386-expand.cc:21870 0x136dd01 ix86_expand_vector_init_duplicate(bool, machine_mode, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/i386-expand.cc:15055 0x1371b6b ix86_expand_vector_init(bool, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/i386-expand.cc:16090 0x1a3c5ad ??? /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/i386/sse.md:26600 0xb347a8 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/recog.h:407 0xb347a8 store_constructor(tree_node*, rtx_def*, int, poly_int<1u, long>, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:7407 0xb3760d expand_constructor /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/e
[Bug analyzer/106741] New: suspicious %qE related warning when building gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741 Bug ID: 106741 Summary: suspicious %qE related warning when building gcc Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- This /usr/local/src/gcc-12.2.0/gcc/analyzer/diagnostic-manager.cc: In member function ‘void ana::saved_diagnostic::dump_as_dot_node(pretty_printer*) const’: /usr/local/src/gcc-12.2.0/gcc/analyzer/diagnostic-manager.cc:783:28: warning: unknown conversion type character ‘E’ in format [-Wformat=] 783 | pp_printf (pp, "var: %qE\n", m_var); |^ /usr/local/src/gcc-12.2.0/gcc/analyzer/diagnostic-manager.cc:783:20: warning: too many arguments for format [-Wformat-extra-args] 783 | pp_printf (pp, "var: %qE\n", m_var); |^~~~ suggests the use of %qE here is wrong, unlike elsewhere in the same file when calling other functions.
[Bug sanitizer/106739] [11/12/13 Regression] runtime error coredump case on c++17/20 since r11-2445-g8c00059ce058ea2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.4
[Bug c++/106740] [11/12 Regression] ICE in instantiate_decl at gcc/cp/pt.cc:26515 since r12-8467-ge057d454db4dcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 Richard Biener changed: What|Removed |Added Known to fail||11.3.1 Priority|P2 |P1 Known to work||11.3.0, 13.0 Target Milestone|12.3|11.4
[Bug c++/106740] [11/12 Regression] ICE in instantiate_decl at gcc/cp/pt.cc:26515 since r12-8467-ge057d454db4dcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Known to work||12.1.0 Known to fail||12.2.0
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 --- Comment #23 from Segher Boessenkool --- (In reply to Andreas Krebbel from comment #22) > The longer a have been looking at these STRICT_LOW_PART issue the more I > think that STRICT_LOW_PART is an awful way to express what we need: > > - the information needed to understand what it is doing is distributed > across 3 RTXs (strict_low_part (subreg:mode1 (reg:mode2 xx) OFS)) > - the big problems arise since the involved RTXs are separately optimized > and we might end up with partial information without a clear definition of > how to deal with that > - actually it is really hard to handle the RTXs as one unit. Recursively > walking RTXs needs to record whether we are in a STRICT_LOW_PART or not. > > > I think it might make sense to explore other ways to express this: > > 1. SUBREG flag - Looks easy, but it would be hard to catch all places which > should care about that flag. > > 2. Introduce a new RTX code which has a mode and an offset attached but does > not require an additional SUBREG anymore. > > 3. Since a STRICT_LOW_PART is essentially a bit insertion operation we could > express it always with a ZERO_EXTRACT target operand and get rid of > STRICT_LOW_PART entirely. A ZERO_EXTRACT would be somewhat more cumbersome > to deal with, since it would always require to check the bit width and > offset for all the cases which just use mode boundaries. But at least most > passes know how to deal with them already. 4. With existing simple RTL: (set (reg:DI x) (ior:DI (and:DI (reg:DI x) (const_int -4294967296)) (zero_extend:DI (reg:SI y (ZERO_EXTRACT is never useful IMNSHO: it just makes the easy cases slightly easier to write, and causes a lot of useless work everywhere else).
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Jakub Jelinek changed: What|Removed |Added Attachment #53506|0 |1 is obsolete|| --- Comment #7 from Jakub Jelinek --- Created attachment 53508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53508&action=edit gcc13-pr106652-wip.patch Further updated patch to kill the never actually used fixed type demangling support from demangler and instead implement the _Float{16,32,64,128} demangling.
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 --- Comment #22 from Andreas Krebbel --- The longer a have been looking at these STRICT_LOW_PART issue the more I think that STRICT_LOW_PART is an awful way to express what we need: - the information needed to understand what it is doing is distributed across 3 RTXs (strict_low_part (subreg:mode1 (reg:mode2 xx) OFS)) - the big problems arise since the involved RTXs are separately optimized and we might end up with partial information without a clear definition of how to deal with that - actually it is really hard to handle the RTXs as one unit. Recursively walking RTXs needs to record whether we are in a STRICT_LOW_PART or not. I think it might make sense to explore other ways to express this: 1. SUBREG flag - Looks easy, but it would be hard to catch all places which should care about that flag. 2. Introduce a new RTX code which has a mode and an offset attached but does not require an additional SUBREG anymore. 3. Since a STRICT_LOW_PART is essentially a bit insertion operation we could express it always with a ZERO_EXTRACT target operand and get rid of STRICT_LOW_PART entirely. A ZERO_EXTRACT would be somewhat more cumbersome to deal with, since it would always require to check the bit width and offset for all the cases which just use mode boundaries. But at least most passes know how to deal with them already.
[Bug c++/106740] [11/12 Regression] ICE in instantiate_decl at gcc/cp/pt.cc:26515 since r12-8467-ge057d454db4dcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |12.3 Summary|Internal compiler error:|[11/12 Regression] ICE in |Segmentation fault |instantiate_decl at ||gcc/cp/pt.cc:26515 since ||r12-8467-ge057d454db4dcf Priority|P3 |P1 --- Comment #3 from Martin Liška --- Started with r12-8467-ge057d454db4dcf.
[Bug c++/106740] Internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 --- Comment #2 from Martin Liška --- Reduced test-case: $ cat ice.ii template struct EnumClass { friend int toString(EnumClass); }; struct AmhsConvInfoCoFw { enum AftnTypeXMsgTypeEnum {}; typedef EnumClass AftnTypeXMsgType; const int getAftnTypeXMsgTypeAsStr() const; struct MtcuAxgwInfo { AftnTypeXMsgType mAftnTypeXMsgType; }; }; const int AmhsConvInfoCoFw::getAftnTypeXMsgTypeAsStr() const { MtcuAxgwInfo __trans_tmp_1; toString(__trans_tmp_1.mAftnTypeXMsgType); return 0; } int toString(AmhsConvInfoCoFw::AftnTypeXMsgType);
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 --- Comment #13 from Eason Lai --- The inline rule in ipa-inline.c::inline_small_functions can be bypassed by adding "noinline" attribute as shown below. __attribute__((weak, noinline)) int get_t(void) { return 0; } It's an alternative solution for me.
[Bug c++/106740] Internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-25 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, bisecting and reducing right now.
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 --- Comment #21 from Andreas Krebbel --- I have committed a patch now which accepts only SUBREGs before reload and then also REGs to deal with how LRA operates right now. I've continued a bit with the patch from Comment 18. It bootstraps on s390x and x86-64. On s390x also the testsuite is clean. However, I see a few failures in the arch specific tests on x86-64. The cases I looked at so far are the result of several peepholes and splitters not being triggered anymore. I've fixed most of them I think but there are also cases where I'm not sure what to do exactly. In case of a matching constraint between a strict_low_part operand and a normal operand. Reload now (with the patch from Comment 18) would remove the subreg on the operand with the matching constraint and would leave it in for the strict_low_part operand. (insn 9 8 16 2 (parallel [ (set (strict_low_part (subreg:QI (reg/v:SI 0 ax [orig:86 a ] [86]) 0)) (and:QI (reg:QI 0 ax [orig:86 a ] [86]) (reg:SI 4 si [92]))) (clobber (reg:CC 17 flags)) ]) "/home/andreas/gcc/gcc/testsuite/gcc.target/i386/pr91188-1a.c":20:10 553 {*andqi_1_slp} (nil)) I think this should be addressed separately. Once we solved it I will adjust the s390x backend again if necessary.
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 --- Comment #12 from Eason Lai --- Hope this information could help. I added "-fopt-info-inline-optimized-missed=inline.txt" in the CFLAGS to see what happens between -Os and -O1. Here is the output when using "-O1": missed: not inlinable: main/5 -> get_t/4, function not inline candidate Here is the output when using "-Os": main.c:13:9: missed: not inlinable: main/5 -> get_t/4, function body can be overwritten at link time optimized: Inlined get_t/4 into main/5 which now has time 3.00 and size 4, net change of +0. It happens in ipa-inline.c::inline_small_functions when using "-O2" or above.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 --- Comment #6 from Jakub Jelinek --- Created attachment 53507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53507&action=edit gcc13-pr106652-bf16.patch And if the answer to 1) is that it is ok for std::bfloat16_t to be __bf16 with u6__bf16 mangling, incremental patch for that. This one doesn't work though, because apparently on none of the 3 targets that do support __bf16 we actually support conversions between __bf16 and other floating point types (most importantly float), nor arithmetic operations (that is quite fatal). So, the important question is if we are ok to add arithmetic operation support to __bf16 and ditto conversions (where arithmetic operations presumably would be implemented by cast to float, arithmetic on float and conversion back?), or if that should be done only on some separate type, whether it is _BFloat16 or __bfloat16_t or whatever else.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Jakub Jelinek changed: What|Removed |Added Attachment #53504|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek --- Created attachment 53506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53506&action=edit gcc13-pr106652-wip.patch Slightly updated patch (mostly to add even more extended testcase).
[Bug c++/106740] New: Internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106740 Bug ID: 106740 Summary: Internal compiler error: Segmentation fault Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kglindemann at yahoo dot de Target Milestone: --- Created attachment 53505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53505&action=edit gzipped report generated by -freport-bug When compiling a c++ file with gcc12.2.0, the compiler crashes. No problems when compiling with gcc12.1
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 --- Comment #20 from CVS Commits --- The master branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:585a21bab3ec688c2039bff2922cc372d8558283 commit r13-2201-g585a21bab3ec688c2039bff2922cc372d8558283 Author: Andreas Krebbel Date: Fri Jul 29 09:55:54 2022 +0200 PR 106101: IBM zSystems: Fix strict_low_part problem This avoids generating illegal (strict_low_part (reg ...)) RTXs. This required two changes: 1. Do not use gen_lowpart to generate the inner expression of a STRICT_LOW_PART. gen_lowpart might fold the SUBREG either because there is already a paradoxical subreg or because it can directly be applied to the register. A new wrapper function makes sure that we always end up having an actual SUBREG. 2. Change the movstrict patterns to enforce a SUBREG as inner operand of the STRICT_LOW_PARTs. The new predicate introduced for the destination operand requires a SUBREG expression with a register_operand as inner operand. However, since reload strips away the majority of the SUBREGs we have to accept single registers as well once we reach reload. Bootstrapped and regression tested on IBM zSystems 64 bit. gcc/ChangeLog: PR target/106101 * config/s390/predicates.md (subreg_register_operand): New predicate. * config/s390/s390-protos.h (s390_gen_lowpart_subreg): New function prototype. * config/s390/s390.cc (s390_gen_lowpart_subreg): New function. (s390_expand_insv): Use s390_gen_lowpart_subreg instead of gen_lowpart. * config/s390/s390.md ("*get_tp_64", "*zero_extendhisi2_31") ("*zero_extendqisi2_31", "*zero_extendqihi2_31"): Likewise. ("movstrictqi", "movstricthi", "movstrictsi"): Use the subreg_register_operand predicate instead of register_operand. gcc/testsuite/ChangeLog: PR target/106101 * gcc.c-torture/compile/pr106101.c: New test.
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 --- Comment #3 from Peter Bergner --- (In reply to Kewen Lin from comment #2) > I wonder if we want to support types __vector_quad and __vector_pair without > MMA support (or supposed to be fixed with Power10 later). If no, we need to > guard register_builtin_type under TARGET_MMA (TARGET_POWER10 later) for > those types. If yes, we may need to revisit its supports. No, the __vector_quad and __vector_pair types should only be used for MMA support. That's not to say in the future that some other different types might produce XOmode and OOmode usage. So basically, the "types" are limited to MMA, but the opaque modes are not limited to MMA.
[Bug sanitizer/106739] [11/12/13 Regression] runtime error coredump case on c++17/20 since r11-2445-g8c00059ce058ea2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-08-25 Summary|runtime error coredump case |[11/12/13 Regression] |on c++17/20 |runtime error coredump case ||on c++17/20 since ||r11-2445-g8c00059ce058ea2a CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-2445-g8c00059ce058ea2a, not clang can't detect that.
[Bug c++/85518] ICE mangling _FloatN types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85518 --- Comment #4 from Jakub Jelinek --- Actually not fully. While it adds mangling for _Float{16,32,64,128}, it doesn't add mangling for _Float{32,64,128}x. https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling doesn't have anything for those and there is no need to add _Float{32,64,128}x support to the C++ FE right now. Perhaps the *x suffixed builtins should be C only?
[Bug c++/85518] ICE mangling _FloatN types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85518 --- Comment #3 from Jakub Jelinek --- The PR106652 WIP patch should fix this.
[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728 Brecht Sanders changed: What|Removed |Added CC||brechtsanders at users dot sourcef ||orge.net --- Comment #7 from Brecht Sanders --- I can confirm it works with the -S flag. Version of binutils is 2.39, so indeed something ma be broken since 2.38.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #25 from Jonathan Wakely --- Yes, and it 1) refers to the key function and 2) is done by the linker not the compiler. Which is what I've been suggesting. If binutils wants to do this and wants to provide a URL, we'll need a more permanent home for the info at https://gcc.gnu.org/wiki/VerboseDiagnostics#undefined_reference_to_vtable_for_X
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-25 CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Kewen Lin --- Confirmed, this got exposed by r13-2062. The commit expects movxo and movoo optab are only used with MMA support (or change with vector pair support on Power10 later) and for related bif expansion erroring. I wonder if we want to support types __vector_quad and __vector_pair without MMA support (or supposed to be fixed with Power10 later). If no, we need to guard register_builtin_type under TARGET_MMA (TARGET_POWER10 later) for those types. If yes, we may need to revisit its supports.
[Bug sanitizer/106739] New: runtime error coredump case on c++17/20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739 Bug ID: 106739 Summary: runtime error coredump case on c++17/20 Product: gcc Version: 10.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zhkefa at live dot cn 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, marxin at gcc dot gnu.org Target Milestone: --- code file test.cc: = class A { public: A(int i): i(i){} int get() {return i;} private: int i{0}; }; void func() { typedef int (A::*f)(); f fs[] = {&A::get}; A *a = new A{1}; for (int i = 0; i < 1; ++i) { (a->*fs[i])(); } delete a; } int main() { func(); return 0; } === envirment: gcc10.4 g++ -fsanitize=address -fsanitize=undefined -std=c++17 test.cc ./a.out runtime error: index 4198816 out of bounds for type func[1] runtime error: load of address 0x7ffd97570f08 whith insufficient space for an object of type 'long int' if compile with -std=c++14 or -std=c++11, everything ok.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #24 from Manuel López-Ibáñez --- For completeness, this is what LLD says: ld.lld: error: undefined symbol: vtable for A >>> referenced by example.cpp:7 >>> /tmp/example-5d8b98.o:(A::A()) >>> the vtable symbol may be undefined because the class is missing its key >>> function (see https://lld.llvm.org/missingkeyfunction) which seems better.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Manuel López-Ibáñez changed: What|Removed |Added Assignee|jyasskin at gmail dot com |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW Last reconfirmed|2010-07-13 22:58:26 |2022-8-25 Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-08/msg00367.htm ||l --- Comment #23 from Manuel López-Ibáñez --- Unassigned so that someone else can take it they wish to.
[Bug tree-optimization/106737] [13 Regression] ICE: verify_ssa failed (error: stmt with wrong VUSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106737 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/106737] [13 Regression] ICE: verify_ssa failed (error: stmt with wrong VUSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106737 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:818073fe9ddc384f0cf702306c672b935fa42325 commit r13-2197-g818073fe9ddc384f0cf702306c672b935fa42325 Author: Richard Biener Date: Thu Aug 25 10:42:30 2022 +0200 tree-optimization/106737 - remove intermediate SSA verification in autopar The following removes intermediate SSA verification in autopar which isn't expected to succeed after previous changes delaying (virtual) SSA update to the end of the pass. PR tree-optimization/106737 * tree-parloops.cc (transform_to_exit_first_loop_alt): Do not verify SSA form. * gcc.dg/autopar/pr106737.c: New testcase.
[Bug tree-optimization/106737] [13 Regression] ICE: verify_ssa failed (error: stmt with wrong VUSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106737 --- Comment #2 from Richard Biener --- OK, easily fixed - transform_to_exit_first_loop_alt performs SSA verification but a previous change delayed all SSA updates so the verification cannot expected to succeed.
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/106737] [13 Regression] ICE: verify_ssa failed (error: stmt with wrong VUSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106737 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-25 Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- Likely caused by my TLC, thanks for the testcase - test coverage of -floop-parallelize is weak.
[Bug c++/106738] -Wlarger-than triggering for *.LASAN0 section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106738 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||diagnostic Last reconfirmed||2022-08-25 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-25 --- Comment #5 from Richard Biener --- (In reply to HaoChen Gui from comment #4) > #define LEN 4 > > struct { > char c[LEN] > } d; > > extern int a; > extern char* b; > > int p() { > for (int i = 0; i < a; i++) { > d.c[i] = b[i]; > } > return 0; > } > > Above codes cause the same errors on x86. When setting the LEN to 8, it can > be also reproduced on aarch64. It's a common problem. > > The iteration number of reset loop after vectorization should not only > decided by variable "a" but also by the length of array. If the len is 5 and > vector size is 4, the reset loop should be only executed once. Currently > iteration number only depends on variable "a". Then it is complete unrolled > 3 times if vector size is 4. That causes the warning. > >[local count: 398179264]: > # i_30 = PHI > _32 = (sizetype) i_30; > _33 = b.0_1 + _32; > _34 = *_33; > d.c[i_30] = _34; > i_36 = i_30 + 1; >if (i_36 < a.1_13) // iterations depend on "a" only, the length of array > is not take into consideration > goto ; [89.00%] > else > goto ; [11.00%] It does take this into account when unrolling. The issue is - at least for the vectorized epilogue - that when we set the iteration bound based on the VF we do not factor in the iteration bound of the scalar loop when we know the vector loop is iterating at least once. That's something we could improve. The real issue is of course that the diagnostic code is too trigger-happy and the unroll code is prone to leaving one not executable iteration (part).
[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316 HaoChen Gui changed: What|Removed |Added CC||guihaoc at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #4 from HaoChen Gui --- #define LEN 4 struct { char c[LEN] } d; extern int a; extern char* b; int p() { for (int i = 0; i < a; i++) { d.c[i] = b[i]; } return 0; } Above codes cause the same errors on x86. When setting the LEN to 8, it can be also reproduced on aarch64. It's a common problem. The iteration number of reset loop after vectorization should not only decided by variable "a" but also by the length of array. If the len is 5 and vector size is 4, the reset loop should be only executed once. Currently iteration number only depends on variable "a". Then it is complete unrolled 3 times if vector size is 4. That causes the warning. [local count: 398179264]: # i_30 = PHI _32 = (sizetype) i_30; _33 = b.0_1 + _32; _34 = *_33; d.c[i_30] = _34; i_36 = i_30 + 1; if (i_36 < a.1_13) // iterations depend on "a" only, the length of array is not take into consideration goto ; [89.00%] else goto ; [11.00%]
[Bug c++/106738] New: -Wlarger-than triggering for *.LASAN0 section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106738 Bug ID: 106738 Summary: -Wlarger-than triggering for *.LASAN0 section Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: frolov.da at phystech dot edu Target Milestone: --- The behaviour of the warning flag -Wlarger-than is described in documentationL > warn whenever an object is defined whose size exceeds byte-size. > -Wlarger-than=‘PTRDIFF_MAX’ is enabled by default. Warnings controlled by the > option can be disabled either by specifying byte-size of ‘SIZE_MAX’ or more > or > by -Wno-larger-than. > Also warn for calls to bounded functions such as memchr or strnlen that > specify a bound greater than the largest possible object, which is > ‘PTRDIFF_MAX’ bytes by default. I've tried to build the next example: #include void foo () { assert (false); } $ g++ -O2 -c -Wlarger-than=16 -fsanitize=address minimal.cpp And got a warning: cc1plus: warning: size of ‘*.LASAN0’ 192 bytes exceeds maximum object size 16 [-Wlarger-than=] It looks like a false triggering. From my point of view the user should not monitor the size of the analyzer section. Moreover, if we would try to add another assert: #include void foo () { assert (false); } void goo () { assert (false); } Then we'll get: cc1plus: warning: size of ‘*.LASAN0’ 256 bytes exceeds maximum object size 16 [-Wlarger-than=]
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #6 from federico --- Yeah this popped up playing with DTIO, this feature is not widely used apparently. I'll also try to get a copy of the gcc source code and build pipeline to see if I can help.