[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=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=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 (>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 (>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 (>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 (>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 (>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 (>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 (>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, );
> 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 (>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 ();
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 (>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=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
[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=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=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=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=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[] = {::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.
[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 #20 from Richard Biener ---
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, );
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.
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).
[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 #19 from Richard Biener ---
(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. */
> + if (dsym == NULL
> + && (dummy = arg->associated_dummy)
> + && dummy->intrinsicness ==
> GFC_NON_INTRINSIC_DUMMY_ARG
> + && dummy->u.non_intrinsic->sym)
> + dsym = dummy->u.non_intrinsic->sym;
> +
> + add_clobber = dsym && dsym->attr.intent == INTENT_OUT
> + && !dsym->attr.allocatable && !dsym->attr.pointer
> && e->symtree && e->symtree->n.sym
> && !e->symtree->n.sym->attr.dimension
> && !e->symtree->n.sym->attr.pointer
>
> Does this fix the remaining issue?
>
> What is the best way to write a testcase that checks that the clobber is
> inserted properly?
For the testcase in comment#8 you could do
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
module error_function
integer, parameter :: r8 = selected_real_kind(12) ! 8 byte real
contains
SUBROUTINE CALERF_r8(ARG, RESULT, JINT)
integer, parameter :: rk = r8
real(rk), intent(in) :: arg
real(rk), intent(out) :: result
IF (Y .LE. THRESH) THEN
END IF
end SUBROUTINE CALERF_r8
FUNCTION DERFC(X)
integer, parameter :: rk = r8 ! 8 byte real
real(rk), intent(in) :: X
real(rk) :: DERFC
CALL CALERF_r8(X, DERFC, JINT)
END FUNCTION DERFC
end module error_function
! { dg-final { scan-tree-dump-not "derfc = {CLOBBER};" } }
tough a more precise test would be to use scan-tree-dump-times "CLOBBER" 1
and scan-tree-dump "__result_derfc = {CLOBBER};". With the bug we 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, );
return __result_derfc;
and corrected there should be either
__result_derfc = {CLOBBER};
instead or the clobber not emitted (for a missed optimization only).
[Bug tree-optimization/106737] New: [13 Regression] ICE: verify_ssa failed (error: stmt with wrong VUSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106737 Bug ID: 106737 Summary: [13 Regression] ICE: verify_ssa failed (error: stmt with wrong VUSE) Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 13.0.0 20220821 snapshot (g:d6a39c25c05c6ed5df8ce49eda719d17e40e29bb) ICEs when compiling gcc/testsuite/gcc.dg/graphite/pr84872.c w/ -O1 -floop-parallelize-all -ftree-parallelize-loops=2 -fno-tree-dce: % gcc-13.0.0 -O1 -floop-parallelize-all -ftree-parallelize-loops=2 -fno-tree-dce -c gcc/testsuite/gcc.dg/graphite/pr84872.c gcc/testsuite/gcc.dg/graphite/pr84872.c: In function 'foo': gcc/testsuite/gcc.dg/graphite/pr84872.c:6:1: error: stmt with wrong VUSE 6 | foo (int x) | ^~~ # .MEM_39 = VDEF <.MEM_30> .paral_data_store.9.x = x_2; expected .MEM_37 during GIMPLE pass: parloops gcc/testsuite/gcc.dg/graphite/pr84872.c:6:1: internal compiler error: verify_ssa failed 0x1148085 verify_ssa(bool, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-ssa.cc:1211 0xfb9a13 try_transform_to_exit_first_loop_alt /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-parloops.cc:2607 0xfb9a13 gen_parallel_loop /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-parloops.cc:3117 0xfbaba6 parallelize_loops /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-parloops.cc:4129 0xfbc1c9 execute /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-parloops.cc:4214 0xfbc1c9 execute /var/tmp/portage/sys-devel/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/tree-parloops.cc:4193
