[Bug tree-optimization/105367] [12 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Ofast -mveclibabi=acml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105367 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-25 Target||x86_64-*-* i?86-*-* Host|x86_64-pc-linux-gnu | Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- Confirmed. ix86_veclibabi_acml expects mathfn_built_in to work on modes but the function instead relies on stricter type equality and thus returns NULL for _Float64. Note mathfn_built_in is only used to get at the base name for the function, it might be easier to manually cover that for the fixed set of functions.
[Bug fortran/105372] The result of the merge function is different when it's type of parameters is the extensions type of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105372 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 105371 ***
[Bug fortran/105371] The result of the merge function is different when it's type of parameters is the extensions type of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371 --- Comment #1 from Andreas Schwab --- *** Bug 105372 has been marked as a duplicate of this bug. ***
[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219 Tamar Christina changed: What|Removed |Added Assignee|tnfchris at gcc dot gnu.org|avieira at gcc dot gnu.org --- Comment #12 from Tamar Christina --- Won't have time to continue on this this week so passing it to Andre in the interest of getting it unblocked sooner.
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 --- Comment #1 from Richard Biener --- I can't reproduce but I also don't see how the code could crash there.
[Bug tree-optimization/105363] -ftree-slp-vectorize decreases performance significantly (x64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105363 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Component|c |tree-optimization Last reconfirmed||2022-04-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #3 from Richard Biener --- t.c:12:14: note: Cost model analysis: _8 1 times scalar_store costs 12 in body _4 1 times scalar_store costs 12 in body *_7 1 times scalar_load costs 12 in body *_3 1 times scalar_load costs 12 in body *_3 1 times vec_perm costs 4 in body *_7 1 times unaligned_load (misalign -1) costs 12 in body _8 1 times unaligned_store (misalign -1) costs 12 in body *_7 1 times vec_to_scalar costs 4 in epilogue *_3 1 times vec_to_scalar costs 4 in epilogue t.c:12:14: note: Cost model analysis for part in loop 2: Vector cost: 36 Scalar cost: 48 t.c:12:14: note: Basic block will be vectorized using SLP which generally looks OK-ish. It's true that GCC could take into account the containing loop which could make it detect the store forwarding problem but currently we are not analyzing data references with respect to any loop for non-loop vectorization.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #30 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79 commit r12-8239-g4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79 Author: Richard Biener Date: Thu Apr 14 14:06:22 2022 +0200 rtl-optimization/105231 - distribute_notes and REG_EH_REGION The following mitigates a problem in combine distribute_notes which places an original REG_EH_REGION based on only may_trap_p which is good to test whether a non-call insn can possibly throw but not if actually it does or we care. That's something we decided at RTL expansion time where we possibly still know the insn evaluates to a constant. In fact, the REG_EH_REGION note with lp > 0 can only come from the original i3 and an assert is added to that effect. That means we only need to retain the note on i3 or, if that cannot trap, drop it but we should never move it to i2. The following places constraints on the insns to combine with non-call exceptions since we cannot handle the case where we have more than one EH side-effect in the IL. The patch also makes sure we can accumulate that on i3 and do not split a possible exception raising part of it to i2. As a special case we do not place any restriction on all externally throwing insns when there is no REG_EH_REGION present. 2022-04-22 Richard Biener PR rtl-optimization/105231 * combine.cc (distribute_notes): Assert that a REG_EH_REGION with landing pad > 0 is from i3. Put any REG_EH_REGION note on i3 or drop it if the insn can not trap. (try_combine): Ensure that we can merge REG_EH_REGION notes with non-call exceptions. Ensure we are not splitting a trapping part of an insn with non-call exceptions when there is any REG_EH_REGION note to preserve. * gcc.dg/torture/pr105231.c: New testcase.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #17 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b6e22db8564827c82108e0b7fa1a84675379c12b commit r12-8240-gb6e22db8564827c82108e0b7fa1a84675379c12b Author: Steve Kargl Date: Mon Apr 25 09:23:56 2022 +0200 target/89125 - BSD and math functions Back story: When GCC is configured and built on non-glibc platforms, it seems very little to no effort is made to enumerate the available C99 libm functions. It is all or nothing for C99 libm. The patch introduces a new function, used on only FreeBSD, to inform gcc that it has C99 libm functions (minus a few which clearly GCC does not check nor test). 2022-04-15 Steven G. Kargl PR target/89125 * config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be bsd_libc_has_function. * targhooks.cc (bsd_libc_has_function): New function. Expand the supported math functions to inclue C99 libm. * targhooks.h (bsd_libc_has_function): New Prototype.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #31 from Richard Biener --- Fixed. Probably not worth fixing the latent issue on branches unless it comes up in real code.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Known to work||12.0 --- Comment #18 from Richard Biener --- Fixed for GCC 12.
[Bug target/105206] mis-optimization with -ffast-math and __builtin_powf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105206 Bug 105206 depends on bug 89125, which changed state. Bug 89125 Summary: Misoptimization of converting sin(x) and cos(x) into sincos(x,&s,&c) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/105369] Improved diagnostics for code from statement expressions documentation [C component]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369 --- Comment #4 from Jonathan Wakely --- The preprocessor can't tell if an expression has side effects. I have no idea how easy it would be (or if it's even possible) for the front end to tell that an expression was duplicated from a single macro argument.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #19 from Steve Kargl --- On Mon, Apr 25, 2022 at 07:28:50AM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 > > Richard Biener changed: > >What|Removed |Added > > Resolution|--- |FIXED > Status|NEW |RESOLVED > Known to work||12.0 > > --- Comment #18 from Richard Biener --- > Fixed for GCC 12. > Thanks.
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from Richard Biener --- Fixed.
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 --- Comment #14 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ab91c10792cd3a1ba1495aa30a34ca17b043bafb commit r12-8241-gab91c10792cd3a1ba1495aa30a34ca17b043bafb Author: Richard Biener Date: Fri Apr 1 11:30:00 2022 +0200 tree-optimization/100810 - avoid undefs in IVOPT rewrites The following attempts to avoid IVOPTs rewriting uses using IV candidates that involve undefined behavior by using uninitialized SSA names. First we restrict the set of candidates we produce for such IVs to the original ones and mark them as not important. Second we try to only allow expressing uses with such IV if they originally use them. That is to avoid rewriting all such uses in terms of other IVs. Since cand->iv and use->iv seem to never exactly match up we resort to comparing the IV bases. The approach ends up similar to the one posted by Roger at https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578441.html but it marks IV candidates rather than use groups and the cases we allow in determine_group_iv_cost_generic are slightly different. 2022-01-04 Richard Biener PR tree-optimization/100810 * tree-ssa-loop-ivopts.cc (struct iv_cand): Add involves_undefs flag. (find_ssa_undef): New function. (add_candidate_1): Avoid adding derived candidates with undefined SSA names and mark the original ones. (determine_group_iv_cost_generic): Reject rewriting uses with a different IV when that involves undefined SSA names. * gcc.dg/torture/pr100810.c: New testcase. * gcc.dg/torture/pr105337.c: Likewise.
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Richard Biener --- Fixed.
[Bug c++/98760] [modules] ICE in add_module_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760 Boris Kolpackov changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Boris Kolpackov --- This appears to be fixed in GCC 12.0.1 20220421.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 98760, which changed state. Bug 98760 Summary: [modules] ICE in add_module_decl https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Let's close this bug, the testcase no longer warns.
[Bug middle-end/104077] bogus/missing -Wdangling-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077 Bug 104077 depends on bug 104076, which changed state. Bug 104076 Summary: bogus -Wdangling-pointer on a conditional https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368
--- Comment #2 from Zdenek Sojka ---
(gdb) disas
Dump of assembler code for function powi_cost(long):
0x01538160 <+0>: push %r14
0x01538162 <+2>: mov$0x20,%ecx
0x01538167 <+7>: push %r13
0x01538169 <+9>: push %r12
0x0153816b <+11>: push %rbp
0x0153816c <+12>: push %rbx
0x0153816d <+13>: mov%rdi,%rbx
0x01538170 <+16>: sub$0x100,%rsp
0x01538177 <+23>: neg%rbx
0x0153817a <+26>: cmovs %rdi,%rbx
0x0153817e <+30>: mov%rsp,%r13
0x01538181 <+33>: xor%eax,%eax
0x01538183 <+35>: xor%r12d,%r12d
0x01538186 <+38>: mov%r13,%rdi
0x01538189 <+41>: rep stos %rax,%es:(%rdi)
0x0153818c <+44>: movb $0x1,0x1(%rsp)
=> 0x01538191 <+49>: cmp$0xff,%rbx
0x01538198 <+56>: jg 0x15381b0
0x0153819a <+58>: jmp0x1538207
1463
1464 /* Ignore the reciprocal when calculating the cost. */
1465 val = (n < 0) ? -n : n;
0x0153816d <+13>: mov%rdi,%rbx
1454powi_cost (HOST_WIDE_INT n)
0x01538170 <+16>: sub$0x100,%rsp
1455{
1456 bool cache[POWI_TABLE_SIZE];
1457 unsigned HOST_WIDE_INT digit;
1458 unsigned HOST_WIDE_INT val;
1459 int result;
1460
1461 if (n == 0)
1462return 0;
--Type for more, q to quit, c to continue without paging--
1463
1464 /* Ignore the reciprocal when calculating the cost. */
1465 val = (n < 0) ? -n : n;
0x01538177 <+23>: neg%rbx
0x0153817a <+26>: cmovs %rdi,%rbx
...
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:
1469 cache[1] = true;
0x0153818c <+44>: movb $0x1,0x1(%rsp)
1472
1473 while (val >= POWI_TABLE_SIZE)
=> 0x01538191 <+49>: cmp$0xff,%rbx
0x01538198 <+56>: jg 0x15381b0
0x0153819a <+58>: jmp0x1538207
(gdb) p/x n
$19 = 0x8000
(gdb) p/x val
$20 = 0x8000
(gdb) p/x $rbx
$22 = 0x8000
The "while (val >= POWI_TABLE_SIZE)" check seems to be done in signed
arithmetics ("jg" conditional jump), so the value is not reduced and cache[i]
accesses out of bounds.
This happens with both boostrapped and non-bootstrapped compiler (using host
gcc-11.3.0)
[Bug middle-end/104492] [12 Regression] Bogus dangling pointer warning at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
--- Comment #9 from Richard Biener ---
So IL wise the issue is that we go from
:
candidates(address-taken)[0].m_size = 2;
candidates(address-taken)[0].m_data = "so";
_1 = std::end (&candidates(address-taken));
_2 = std::begin (&candidates(address-taken));
_11 = std::find (_2, _1,
&s(address-taken));
_3 = _11;
_4 = std::end (&candidates(address-taken));
_13 = _3 != _4;
candidates(address-taken) ={v} {CLOBBER(eol)};
return _13;
to
_32 = std::__find_if >
(&candidates(address-taken), &MEM [(void
*)&candidates(address-taken) + 16B], __pred, D.182436);
__pred ={v} {CLOBBER(eol)};
_33 = &MEM [(void
*)&candidates(address-taken) + 16B] != _32;
candidates(address-taken) ={v} {CLOBBER(eol)};
_66 = _33;
s(address-taken) ={v} {CLOBBER(eol)};
_19 = _66;
retval.0_20 = _19;
D.169966(address-taken) ={v} {CLOBBER(eol)};
if (retval.0_20 != 0)
exposing the forwarding opportunity into the conditional:
_32 = std::__find_if >
(&candidates(address-taken), &MEM [(void
*)&candidates(address-taken) + 16B], __pred, D.182436);
__pred ={v} {CLOBBER(eol)};
candidates(address-taken) ={v} {CLOBBER(eol)};
s(address-taken) ={v} {CLOBBER(eol)};
D.169966 ={v} {CLOBBER(eol)};
if (&MEM [(void *)&candidates(address-taken)
+ 16B] != _32)
as noted CLOBBERs are not barriers for values but only for memory so any
such forwarding (which would also happen for non-equality compares) interferes
with the intent of -Wdangling-pointer. I'll note that a CLOBBER does _not_
invalidate the pointer to the storage but only its contents as opposed to
some reading of 'realloc' or 'free' semantics imposed by the C standard.
The documentation mentions two levels of -Wdangling-pointer but all examples
are about either the pointer escaping the function (to the caller) or about
accesses to the storage whose contents became indeterminate.
Unrolling and IVOPTs/SLSR could also expose re-use of storage accessed by
a pointer to the "first" instance of a variable.
I'm not sure what can be done about all this for the late pass_warn_access
(which runs _very_ late). It's going to be prone to such issues and
maybe -Wanalyzer is a better tool for the purpose.
I was not successful in auto-reducing the testcase to something that
closely resembles the above IL but I guess crafting a manual testcase
from it would be possible.
For the specific case we now pass 'equality' to
pass_waccess::warn_invalid_pointer which is true for the original testcase
but is only used to prune diagnostics after free/realloc and not when
using the (undocumented) -Wdangling-pointer=3 level (level 3 is also rejected
because it has IntegerRange(0, 2)).
This case is about iteration over an auto variable and the "found" check
being forwarded across the storage invalidation.
The following fixes the original (and my misreduced) testcase. I'm going
to test it and post it for review.
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 879dbcc1e52..6c404f18db7 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -3896,13 +3896,13 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple
*us
e_stmt,
return;
}
+ if ((equality && warn_use_after_free < 3)
+ || (maybe && warn_use_after_free < 2)
+ || warning_suppressed_p (use_stmt, OPT_Wuse_after_free))
+return;
+
if (is_gimple_call (inval_stmt))
{
- if ((equality && warn_use_after_free < 3)
- || (maybe && warn_use_after_free < 2)
- || warning_suppressed_p (use_stmt, OPT_Wuse_after_free))
- return;
-
const tree inval_decl = gimple_call_fndecl (inval_stmt);
if ((ref && warning_at (use_loc, OPT_Wuse_after_free,
@@ -3923,10 +3923,6 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple
*use_stmt,
return;
}
- if ((maybe && warn_dangling_pointer < 2)
- || warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
-return;
-
if (DECL_NAME (var))
{
if ((ref
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 --- Comment #3 from Zdenek Sojka --- I think the issue might be in the: > 1463 > 1464 /* Ignore the reciprocal when calculating the cost. */ > 1465 val = (n < 0) ? -n : n; expression, for the case n == LONG_MIN, but I am not a language lawyer. (-n is not representable in the (promoted) signed type)
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-04-25 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- (In reply to Zdenek Sojka from comment #3) > I think the issue might be in the: > > > 1463 > > 1464 /* Ignore the reciprocal when calculating the cost. */ > > 1465 val = (n < 0) ? -n : n; > > expression, for the case n == LONG_MIN, but I am not a language lawyer. (-n > is not representable in the (promoted) signed type) Ah, good point. diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc index 102b7a2cc99..7555793948e 100644 --- a/gcc/tree-ssa-math-opts.cc +++ b/gcc/tree-ssa-math-opts.cc @@ -1462,7 +1462,7 @@ powi_cost (HOST_WIDE_INT n) return 0; /* Ignore the reciprocal when calculating the cost. */ - val = (n < 0) ? -n : n; + val = absu_hwi (n); /* Initialize the exponent cache. */ memset (cache, 0, POWI_TABLE_SIZE * sizeof (bool)); should fix that.
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 --- Comment #5 from Andrew Pinski --- Might be easier to reproduce using ubsan too.
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358 --- Comment #1 from Jakub Jelinek --- That change was completely intentional, to fix Solaris/x86 etc. If there is not an efficient aligned alloc, we don't want struct gomp_work_share to require 64-byte alignment (because normal allocator can't handle that and the emulated allocator is too costly) and just want to make sure the two parts are 64-bytes appart. The structure contains long long members, but sure, on ia32 long long has smaller alignment in structures than __alignof__(long long). Now, not really sure why does this matter if struct gomp_workshare is malloced, the whole struct should get aligned to whatever malloc guarantees and that better should include long long alignment. Is this about struct gomp_work_share work_shares[8]; in struct gomp_team then? We could for the #ifndef GOMP_USE_ALIGNED_WORK_SHARES case perhaps add __attribute__((aligned (MAX (__alignof__ (struct gomp_work_share), __alignof__(long long or so?
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358
--- Comment #2 from Jakub Jelinek ---
Does
--- libgomp/libgomp.h.jj2022-01-11 23:11:23.890269075 +0100
+++ libgomp/libgomp.h 2022-04-25 11:20:09.744103064 +0200
@@ -717,6 +717,13 @@ struct gomp_team
/* This barrier is used for most synchronization of the team. */
gomp_barrier_t barrier;
+#ifndef GOMP_USE_ALIGNED_WORK_SHARES
+ /* If struct gomp_work_share isn't 64-byte aligned, ensure it is
+ at least 8-byte aligned because __alignof__ (long long) is used
+ for the inline_ordered_team_ids handling. */
+ struct { } pad __attribute__((aligned (__alignof__ (long long;
+#endif
+
/* Initial work shares, to avoid allocating any gomp_work_share
structs in the common case. */
struct gomp_work_share work_shares[8];
fix it?
[Bug target/104662] arm: ice in simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662 Christophe Lyon changed: What|Removed |Added Last reconfirmed||2022-04-25 Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug c++/105373] New: miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
Bug ID: 105373
Summary: miscompile involving lambda coroutines and an object
bitwise copied instead of via the copy constructor
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: avi at scylladb dot com
Target Milestone: ---
This is a bug in a complex piece of code, so I'll need guidance on what further
information to provide (e.g. intermediate code dumps). It reproduces with
various levels of debug information, and the code works with clang.
At the heart there is a shared pointer, which I've enhanced so that all
pointers that point to the same object keep track of each other (also the
pointee points back to one of the pointers). The pointee keeps an incrementing
generation count. In the end I have two pointer objects that are bitwise equal,
even though they should have different generation counts and different
doubly-linked-list pointers. This proves that a bitwise copy happened. It
doesn't prove a miscompile, since my code could have decided to perform a
bitwise copy, but the fact that it works in clang indicates it's a gcc bug. The
bug happens with asan too, and with different sizeof(the smart pointer) so it's
not some stray write.
This is the snippet that causes the trouble:
0tlogger.info("before updating cache {}",
fmt::ptr(old3.get()));
1co_await
with_scheduling_group(_config.memtable_to_cache_scheduling_group, [this, old4 =
old3, &newtabs] () -> future<> {
2tlogger.info("updating cache {}", fmt::ptr(old4.get()));
3return update_cache(old4, newtabs);
4});
old3 and old4 are all copies of the same smart pointer (there are also old and
old1 and old2 elsewhere, but they are correct). In the call to update_cache(),
we attempt to make a copy of old4, and an internal check finds the link list is
corrupted. Inspecting old4 in the debugger (from the printout in line 0) and
the source of the copy in line 3 shows they are the same, but have different
addresses:
0 INFO 2022-04-25 12:04:14,722 [shard 0] table - before updating cache
0x60666c40
1 copying @0x6520bef8 <- @0x652108f0 0x60666c40 refcnt 6 gen 43
2 INFO 2022-04-25 12:04:14,722 [shard 0] table - updating cache 0x60666c40
3 (gdb) p this
$1 = (const seastar::lw_shared_ptr * const) 0x6520bed0
4 (gdb) p *this
5 $2 = {_ptr = 0x60666c40, _next = 0x652108f0, _prev = 0x6597ae48,
_generation = 43}
6 (gdb) x/4gx 0x6520bef8
7 0x6520bef8: 0x60666c40 0x652108f0
8 0x6520bf08: 0x6597ae48 0x002b
9 (gdb) x/4gx this
10 0x6520bed0: 0x60666c40 0x652108f0
11 0x6520bee0: 0x6597ae48 0x002b
in line 3 I dump old4 (from the printout in line 1, where old3 is copied into
old4). But "this" doesn't point to old4., it points to a bitwise copy of old4,
as shown in lines 7-8 and 10-11.
Note that both old4 and the bad copy "this" are members of the coroutine frame.
I realize this isn't enough to analyze the situation, I'm happy to provide more
information if you direct me how.
[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #32 from Richard Biener ---
So the bad "head" can be fixed via
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index c74edd1aaef..8f9f26e0a82 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3580,9 +3580,9 @@
;; Possible store forwarding (partial memory) stall in alternatives 4, 6 and
7.
(define_insn "*movdf_internal"
[(set (match_operand:DF 0 "nonimmediate_operand"
-"=Yf*f,m ,Yf*f,?r ,!o,?*r ,!o,!o,?r,?m,?r,?r,v,v,v,m,*x,*x,*x,m ,r ,v,r
,o ,r ,m")
+"=Yf*f,m ,Yf*f,?r ,!o,?*r ,!o,!o,?r,?m,?r,?r,v,v,v,m,*x,*x,*x,m ,!r,!v,r
,o ,r ,m")
(match_operand:DF 1 "general_operand"
-"Yf*fm,Yf*f,G ,roF,r ,*roF,*r,F ,rm,rC,C ,F ,C,v,m,v,C ,*x,m ,*x,v,r
,roF,rF,rmF,rC"))]
+"Yf*fm,Yf*f,G ,roF,r ,*roF,*r,F ,rm,rC,C ,F ,C,v,m,v,C ,*x,m
,*x,!v,!r,roF,rF,rmF,rC"))]
"!(MEM_P (operands[0]) && MEM_P (operands[1]))
&& (lra_in_progress || reload_completed
|| !CONST_DOUBLE_P (operands[1])
which is adding ! to r<->v alternatives. That should eventually be done
by duplicating the alternatives and enabling one set via some enable
attribute based on some tunable. I see those alternatives are already
(set (attr "preferred_for_speed")
(cond [(eq_attr "alternative" "3,4")
(symbol_ref "TARGET_INTEGER_DFMODE_MOVES")
(eq_attr "alternative" "20")
(symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
(eq_attr "alternative" "21")
(symbol_ref "TARGET_INTER_UNIT_MOVES_TO_VEC")
]
(symbol_ref "true")))
not sure why it's preferred_for_speed here though - shouldn't that be
enabled for size if !TARGET_INTER_UNIT_MOVES_{TO,FROM}_VEC and otherwise
disabled? Not sure if combining enabled and preferred_for_speed is
reasonably possible, but we have a preferred_for_size attribute here.
The diff with ! added is quite short, I've yet have to measure any
effect on LBM:
--- streamcollide.s.orig2022-04-25 11:37:01.638733951 +0200
+++ streamcollide.s22022-04-25 11:35:54.885849296 +0200
@@ -33,28 +33,24 @@
.p2align 4
.p2align 3
.L12:
- movq.LC0(%rip), %rax
- vmovsd .LC4(%rip), %xmm6
+ vmovsd .LC0(%rip), %xmm2
+ vmovsd .LC1(%rip), %xmm13
+ movabsq $0x3ff01878b7a1c25d, %rax
movabsq $0x3fef85af6c69b5a6, %rdi
+ vmovsd .LC2(%rip), %xmm12
+ vmovsd .LC3(%rip), %xmm14
movabsq $0x3ff03db8fde2ef4e, %r8
+ movabsq $0x3fefcea39c51dabe, %r9
+ vmovsd .LC4(%rip), %xmm6
vmovsd .LC5(%rip), %xmm7
movq.LC8(%rip), %r11
- movabsq $0x3fefcea39c51dabe, %r9
movq.LC6(%rip), %rdx
movq.LC7(%rip), %rcx
- vmovq %rax, %xmm2
- vmovq %rax, %xmm4
- movq.LC1(%rip), %rax
movq%r11, %rsi
movq%r11, %r12
- vmovq %rax, %xmm13
- vmovq %rax, %xmm8
- movq.LC2(%rip), %rax
- vmovq %rax, %xmm12
- vmovq %rax, %xmm5
- movq.LC3(%rip), %rax
- vmovq %rax, %xmm14
- movabsq $0x3ff01878b7a1c25d, %rax
+ vmovsd %xmm2, %xmm2, %xmm4
+ vmovsd %xmm13, %xmm13, %xmm8
+ vmovsd %xmm12, %xmm12, %xmm5
vmovsd %xmm14, -16(%rsp)
.L5:
vmulsd .LC9(%rip), %xmm0, %xmm3
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f0e170f72f8bfaa2a64e1d09ebdfd48f917420f1 commit r12-8242-gf0e170f72f8bfaa2a64e1d09ebdfd48f917420f1 Author: Richard Biener Date: Mon Apr 25 10:55:21 2022 +0200 tree-optimization/105368 - avoid overflow in powi_cost The following avoids undefined signed overflow when computing the absolute of the exponent in powi_cost. 2022-04-25 Richard Biener PR tree-optimization/105368 * tree-ssa-math-opts.cc (powi_cost): Use absu_hwi.
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358
--- Comment #3 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #2)
> Does
> --- libgomp/libgomp.h.jj 2022-01-11 23:11:23.890269075 +0100
> +++ libgomp/libgomp.h 2022-04-25 11:20:09.744103064 +0200
> @@ -717,6 +717,13 @@ struct gomp_team
>/* This barrier is used for most synchronization of the team. */
>gomp_barrier_t barrier;
>
> +#ifndef GOMP_USE_ALIGNED_WORK_SHARES
> + /* If struct gomp_work_share isn't 64-byte aligned, ensure it is
> + at least 8-byte aligned because __alignof__ (long long) is used
> + for the inline_ordered_team_ids handling. */
> + struct { } pad __attribute__((aligned (__alignof__ (long long;
> +#endif
> +
>/* Initial work shares, to avoid allocating any gomp_work_share
> structs in the common case. */
>struct gomp_work_share work_shares[8];
> fix it?
unfortunately, no presumably the size of gomp_work_share is a multiple
of 4 bytes, whatwe need is to make the align of gomp_work_share at least
'long long'.
[Bug tree-optimization/105368] [10/11/12 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 --- Comment #7 from Zdenek Sojka --- I can confirm the patch fixes the testcase for me.
[Bug tree-optimization/105368] [10/11 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 Richard Biener changed: What|Removed |Added Known to fail|12.0| Summary|[10/11/12 Regression] ICE: |[10/11 Regression] ICE: |SIGSEGV in powi_lookup_cost |SIGSEGV in powi_lookup_cost |(tree-ssa-math-opts.cc:1441 |(tree-ssa-math-opts.cc:1441 |) with -Ofast and |) with -Ofast and |__builtin_powf()|__builtin_powf() Known to work||12.0 --- Comment #8 from Richard Biener --- Thanks.
[Bug tree-optimization/105368] [10/11 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |10.4
[Bug tree-optimization/105367] [12 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Ofast -mveclibabi=acml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105367 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 52863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52863&action=edit gcc12-pr105367.patch Untested fix.
[Bug tree-optimization/105367] [12 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Ofast -mveclibabi=acml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105367 --- Comment #3 from Jakub Jelinek --- Created attachment 52864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52864&action=edit gcc12-pr105367-2.patch Variant patch (smaller, just i386 backend). Advantage of the first one is that we can use that elsewhere later on.
[Bug tree-optimization/105367] [12 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Ofast -mveclibabi=acml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105367 --- Comment #4 from Richard Biener --- (In reply to Jakub Jelinek from comment #3) > Created attachment 52864 [details] > gcc12-pr105367-2.patch > > Variant patch (smaller, just i386 backend). Advantage of the first one is > that > we can use that elsewhere later on. This one is certainly obvious. I'm less sure about mapping back modes to _Float and then the corresponding library functions - can we not get into the situation choosing 'double' for SFmode (on targets where double == float) but the target only having sinf() but not sin()? I guess we have to be more clever wrt libm.libc_has_function () and choosing the function when we have multiple choices?
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 --- Comment #1 from Avi Kivity --- I randomly looked at 023t.ssa (mainly because I recognized the acronym). _45 = frame_ptr_182(D)->__closure; _46 = _45->__this; frame_ptr_182(D)->D.2159984_4_7 = _46->_config.memtable_to_cache_scheduling_group; _47 = &frame_ptr_182(D)->D.2159792_4_7; _48 = frame_ptr_182(D)->__closure; _49 = &_48->__old3; seastar::lw_shared_ptr::lw_shared_ptr (_47, _49); _50 = frame_ptr_182(D)->__closure; _51 = _50->__this; frame_ptr_182(D)->D.2159793_4_7.__this = _51; frame_ptr_182(D)->D.2159793_4_7.__old4 = frame_ptr_182(D)->D.2159792_4_7; _52 = frame_ptr_182(D)->__closure; _53 = _52->__newtabs; frame_ptr_182(D)->D.2159793_4_7.__newtabs = _53; _54 = &frame_ptr_182(D)->D.2159793_4_7; frame_ptr_182(D)->D.2160366_4_7 = seastar::with_scheduling_group, sstable_write_permit&&)::_ZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permit.Frame*)operator()(replica::table::try_flush_memtable_to_sstable(replica::table::try_flush_memtable_to_sstable(seastar::lw_shared_ptr, sstable_write_permit&&)::_ZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permit.Frame*):: mutable::_ZZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permitENUlvE_clEv.Frame*)operator()(replica::table::try_flush_memtable_to_sstable(replica::table::try_flush_memtable_to_sstable(seastar::lw_shared_ptr, sstable_write_permit&&)::_ZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permit.Frame*)operator()(replica::table::try_flush_memtable_to_sstable(replica::table::try_flush_memtable_to_sstable(seastar::lw_shared_ptr, sstable_write_permit&&)::_ZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permit.Frame*):: mutable::_ZZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permitENUlvE_clEv.Frame*):: mutable::_ZZZN7replica5table29try_flush_memtable_to_sstableEN7seastar13lw_shared_ptrINS_8memtableEEEO20sstable_write_permitENUlvE_clEvENUlvE1_clEv.Frame*):: > (frame_ptr_182(D)->D.2159984_4_7, _54); [return slot optimization] _55 = &frame_ptr_182(D)->D.2160366_4_7; frame_ptr_182(D)->Aw5_4_7 = seastar::operator co_await (_55); [return slot optimization] In the line frame_ptr_182(D)->D.2159793_4_7.__old4 = frame_ptr_182(D)->D.2159792_4_7; Is this not a bitwise copy, which should be instead a call to the copy constructor?
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358 --- Comment #4 from Jakub Jelinek --- Still trying to understand where the problem is. In work.c (gomp_init_work_share), there are 3 cases, one is ordered == 0, another one ordered == 1, another one bigger numbers. The first one doesn't care, ordered_team_ids is initialized to inline_ordered_team_ids just to make sure we don't try to team_free it, isn't really used. For ordered == 1 case, we only use the trailing array as array of unsigned and most likely in the darwin9 case not at all, because I expect INLINE_ORDERED_TEAM_IDS_SIZE to be 0 or 4 or something that small. For the ordered > 1 case (used when some memory needs to be allocated after the ordered_teams_ids array and that one should be possibly 8-byte aligned) it adds extra __alignof__ (long long) - 1 to the size but undoes that if nthreads is even and inline_ordered_team_ids is at position divisible by 8. So, guess some question, can you e.g. from dumping DWARF on work.o find out: sizeof (struct gomp_init_work_share) offsetof (struct gomp_init_work_share, inline_ordered_team_ids) ?
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 --- Comment #22 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:6cc26f3037a18b9a958b4ac2a1363149a7fccd39 commit r12-8243-g6cc26f3037a18b9a958b4ac2a1363149a7fccd39 Author: Mikael Morin Date: Mon Apr 25 13:14:20 2022 +0200 testsuite: add additional option to force DSE execution [PR103662] This fixes a dump tree match check that is UNRESOLVED with the -O0 optimization option, as the optimization pass corresponding to the dump file is not run at -O0, and the dump is not generated. PR fortran/103662 gcc/testsuite/ChangeLog: * gfortran.dg/unlimited_polymorphic_3.f03: Force execution of the DSE optimization pass.
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358 --- Comment #5 from Jakub Jelinek --- Or is the problem mainly in code like #define INLINE_ORDERED_TEAM_IDS_OFF \ ((offsetof (struct gomp_work_share, inline_ordered_team_ids) \ + __alignof__ (long long) - 1) & ~(__alignof__ (long long) - 1)) if (size > (sizeof (struct gomp_work_share) - INLINE_ORDERED_TEAM_IDS_OFF)) where if struct gomp_work_share's size equal to inline_ordered_team_ids isn't a multiple of 8 sizeof (struct gomp_work_share) - INLINE_ORDERED_TEAM_IDS_OFF wraps around?
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358
--- Comment #6 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #4)
> Still trying to understand where the problem is.
> In work.c (gomp_init_work_share), there are 3 cases, one is ordered == 0,
> another one ordered == 1, another one bigger numbers. The first one doesn't
> care,
> ordered_team_ids is initialized to inline_ordered_team_ids just to make sure
> we don't try to team_free it, isn't really used. For ordered == 1 case, we
> only use the trailing array as array of unsigned and most likely in the
> darwin9 case not at all, because I expect INLINE_ORDERED_TEAM_IDS_SIZE to be
> 0 or 4 or something that small.
> For the ordered > 1 case (used when some memory needs to be allocated after
> the
> ordered_teams_ids array and that one should be possibly 8-byte aligned) it
> adds extra __alignof__ (long long) - 1 to the size but undoes that if
> nthreads is even and inline_ordered_team_ids is at position divisible by 8.
>
> So, guess some question, can you e.g. from dumping DWARF on work.o find out:
> sizeof (struct gomp_init_work_share)
> offsetof (struct gomp_init_work_share, inline_ordered_team_ids)
> ?
(sorry for being slow here, meetings...)
so 0xac = 172 .. and therefore as you expected INLINE_ORDERED_TEAM_IDS_SIZE = 0
(that's on a 8 core / 16 thread machine)
0x0dc5: TAG_structure_type [22] *
AT_name( "gomp_work_share" )
AT_byte_size( 0xac )
AT_decl_file( "/src-local/gcc-master/libgomp/libgomp.h" )
AT_decl_line( 288 )
AT_decl_column( 0x08 )
AT_sibling( {0x0f0a} )
0x0ee4: TAG_member [23]
AT_name( "inline_ordered_team_ids" )
AT_decl_file( "/src-local/gcc-master/libgomp/libgomp.h" )
AT_decl_line( 395 )
AT_decl_column( 0x0c )
AT_type( {0x1051} ( unsigned int[] ) )
AT_data_member_location( +172 )
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358 --- Comment #7 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #5) > Or is the problem mainly in code like > #define INLINE_ORDERED_TEAM_IDS_OFF \ > ((offsetof (struct gomp_work_share, inline_ordered_team_ids) \ > + __alignof__ (long long) - 1) & ~(__alignof__ (long long) - 1)) > if (size > (sizeof (struct gomp_work_share) > - INLINE_ORDERED_TEAM_IDS_OFF)) > where if struct gomp_work_share's size equal to inline_ordered_team_ids > isn't a multiple of 8 sizeof (struct gomp_work_share) - > INLINE_ORDERED_TEAM_IDS_OFF wraps around? right - I suspect that could be the case because sizeof (struct gomp_work_share) is not a multiple of 8.
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358 --- Comment #8 from Jakub Jelinek --- Created attachment 52865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52865&action=edit gcc12-pr105358.patch So what about this? All the newly added comparisons should fold into true or false at compile time.
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #2 from Avi Kivity ---
I see it in 006t.gimple too:
try
{
_50 = frame_ptr->__closure;
_51 = _50->__this;
frame_ptr->D.2159793_4_7.__this = _51;
frame_ptr->D.2159793_4_7.__old4 =
frame_ptr->D.2159792_4_7;
_52 = frame_ptr->__closure;
_53 = _52->__newtabs;
frame_ptr->D.2159793_4_7.__newtabs = _53;
newtabs is captured by reference, so the copy from _53 is reasonable. But old4
is captured by value, and so should go through the copy constructor.
Looking at references to old3, it always has its address taken and then passed
to the copy constructor.
[Bug tree-optimization/105374] New: [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
Bug ID: 105374
Summary: [12 Regression] ICE in fold_convert_loc, at
fold-const.cc:2580 during GIMPLE pass: reassoc since
r12-7338-g884f77b489510e1df9db2889b60c5df6fcda
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat t.cc
typedef float v4f __attribute__((vector_size(4 * sizeof(float;
v4f f_x, f_y;
long f() { return (f_x < f_y | f_x <= f_y)[2]; }
$ ./arm-eabi-gcc -c t.cc -march=armv8.1-m.main+mve -mfloat-abi=hard -O
during GIMPLE pass: reassoc
t.cc: In function 'long int f()':
t.cc:3:6: internal compiler error: in fold_convert_loc, at fold-const.cc:2580
3 | long f() { return (f_x < f_y | f_x <= f_y)[2]; }
| ^
0xcb5136 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/fold-const.cc:2580
0x12ef522 eliminate_redundant_comparison
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:2257
0x12ef522 optimize_ops_list
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:2448
0x12f5a0b reassociate_bb
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:6737
0x12f8496 reassociate_bb
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:6899
0x12f8929 do_reassoc
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:7011
0x12f8929 execute_reassoc
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:7100
0x12f8929 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-reassoc.cc:7141
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 Alex Coplan changed: What|Removed |Added Known to fail||12.0 Known to work||11.3.1 Keywords||ice-on-valid-code Target||arm-eabi --- Comment #1 from Alex Coplan --- I should have mentioned the testcase is reduced from g++.dg/other/pr95231.C
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 --- Comment #3 from Avi Kivity --- I see this alleged copy in gcc 10.2.1 too.
[Bug libstdc++/105375] New: std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375
Bug ID: 105375
Summary: std::packaged_task has no deduction guide.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: raldone01 at gmail dot com
Target Milestone: ---
According to cppreference
https://en.cppreference.com/w/cpp/thread/packaged_task/deduction_guides
std::packaged_task should have a deduction guide.
The example listed on their page does not compile.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
System type: Ubuntu WSL
Command line: c++ -Wall -Wextra -g -std=gnu++20 -o lin.obj -c main.cpp
Expected behavior: The snipped from cppreference compiles.
Actual behavior: The deduction guide for packaged_task is missing?
int func(double) { return 0; }
int main() {
std::packaged_task f{func}; // deduces packaged_task
int i = 5;
std::packaged_task g = [&](double) { return i; }; // deduces
packaged_task
}
As std::function has deduction guides shouldn't std::packaged_task have some
too?
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #1 from raldone01 --- Created attachment 52866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52866&action=edit main.cpp
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #2 from raldone01 --- Created attachment 52867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52867&action=edit All the request files.
[Bug sanitizer/105347] Failed to build from source on FreeBSD 11.* due to using nonexistent sha224.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105347 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-04-25 --- Comment #1 from Martin Liška --- Please report it to upstream: https://github.com/llvm/llvm-project/issues It's these since the following review: https://reviews.llvm.org/D110989
[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 --- Comment #33 from Richard Biener --- (In reply to Richard Biener from comment #32) > The diff with ! added is quite short, I've yet have to measure any > effect on LBM: > > --- streamcollide.s.orig2022-04-25 11:37:01.638733951 +0200 > +++ streamcollide.s22022-04-25 11:35:54.885849296 +0200 > @@ -33,28 +33,24 @@ > .p2align 4 > .p2align 3 > .L12: > - movq.LC0(%rip), %rax > - vmovsd .LC4(%rip), %xmm6 > + vmovsd .LC0(%rip), %xmm2 > + vmovsd .LC1(%rip), %xmm13 > + movabsq $0x3ff01878b7a1c25d, %rax > movabsq $0x3fef85af6c69b5a6, %rdi > + vmovsd .LC2(%rip), %xmm12 > + vmovsd .LC3(%rip), %xmm14 > movabsq $0x3ff03db8fde2ef4e, %r8 > + movabsq $0x3fefcea39c51dabe, %r9 > + vmovsd .LC4(%rip), %xmm6 > vmovsd .LC5(%rip), %xmm7 > movq.LC8(%rip), %r11 > - movabsq $0x3fefcea39c51dabe, %r9 > movq.LC6(%rip), %rdx > movq.LC7(%rip), %rcx > - vmovq %rax, %xmm2 > - vmovq %rax, %xmm4 > - movq.LC1(%rip), %rax > movq%r11, %rsi > movq%r11, %r12 > - vmovq %rax, %xmm13 > - vmovq %rax, %xmm8 > - movq.LC2(%rip), %rax > - vmovq %rax, %xmm12 > - vmovq %rax, %xmm5 > - movq.LC3(%rip), %rax > - vmovq %rax, %xmm14 > - movabsq $0x3ff01878b7a1c25d, %rax > + vmovsd %xmm2, %xmm2, %xmm4 > + vmovsd %xmm13, %xmm13, %xmm8 > + vmovsd %xmm12, %xmm12, %xmm5 > vmovsd %xmm14, -16(%rsp) > .L5: > vmulsd .LC9(%rip), %xmm0, %xmm3 Huh, and the net effect is that the + code is 9% _slower_!?
[Bug lto/105364] lto-wrapper generates URLs escape sequences despite -fdiagnostic-urls=never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105364 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- Let me fix that.
[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #34 from Richard Biener ---
As noted the effect of
if(...) {
ux = 0.005;
uy = 0.002;
uz = 0.000;
}
is PRE of most(!) dependent instructions, creating
# prephitmp_1099 = PHI <_1098(6),
6.4997172499889149648879538290202617645263671875e-1(5)>
# prephitmp_ = PHI <_1110(6),
1.08980570833178483570691241766326129436492919921875e-1(5)>
...
we successfully coalesce the non-constant incoming register with the result
but have to emit copies for all constants on the other edge where we have
quite a number of duplicate constants to deal with.
I've experimented with ensuring we get _full_ PRE of the dependent expressions
by more aggressively re-associating (give PHIs with a constant incoming operand
on at least one edge a rank similar to constants, 1).
This increases the number of PHIs further but reduces the followup computations
more. We still fail to simply tail-duplicate the merge block - another
possibility to eventually save some of the overhead, our tail duplication
code (gimple-ssa-split-paths.cc) doesn't handle this case since the
diamond is not the one immediately preceeding the loop exit/latch.
The result of "full PRE" is a little bit worse than the current state (so
it's not a full solution here).
[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
Richard Biener changed:
What|Removed |Added
Target Milestone|12.0|13.0
Priority|P1 |P2
--- Comment #35 from Richard Biener ---
(In reply to Richard Biener from comment #34)
> As noted the effect of
>
> if(...) {
>ux = 0.005;
>uy = 0.002;
>uz = 0.000;
> }
>
> is PRE of most(!) dependent instructions, creating
>
> # prephitmp_1099 = PHI <_1098(6),
> 6.4997172499889149648879538290202617645263671875e-1(5)>
> # prephitmp_ = PHI <_1110(6),
> 1.08980570833178483570691241766326129436492919921875e-1(5)>
> ...
>
> we successfully coalesce the non-constant incoming register with the result
> but have to emit copies for all constants on the other edge where we have
> quite a number of duplicate constants to deal with.
>
> I've experimented with ensuring we get _full_ PRE of the dependent
> expressions
> by more aggressively re-associating (give PHIs with a constant incoming
> operand
> on at least one edge a rank similar to constants, 1).
>
> This increases the number of PHIs further but reduces the followup
> computations
> more. We still fail to simply tail-duplicate the merge block - another
> possibility to eventually save some of the overhead, our tail duplication
> code (gimple-ssa-split-paths.cc) doesn't handle this case since the
> diamond is not the one immediately preceeding the loop exit/latch.
>
> The result of "full PRE" is a little bit worse than the current state (so
> it's not a full solution here).
Btw, looking at coverage the constant case is only an umimportant fraction
of the runtime, so the register pressure increase by the PRE dominates
(but the branch is predicted to be 50/50):
3562383000: 241: if( TEST_FLAG_SWEEP( srcGrid, ACCEL )) {
55296000: 242:ux = 0.005;
55296000: 243:uy = 0.002;
55296000: 244:uz = 0.000;
-: 245:}
we can also see that PGO notices this and we do _not_ perform the PRE.
So the root cause is nothing we can fix for GCC 12, tuning to avoid
spilling to GPRs can recover parts of the regression but will definitely
have effects elsewhere.
Re-targeting to GCC 13.
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-25 --- Comment #3 from Jonathan Wakely --- cppreference says it's defined since C++17 but that's wrong, it was a post-C++20 LWG issue: https://cplusplus.github.io/LWG/issue3117 We don't implement it yet.
[Bug tree-optimization/102879] [12 Regression] Dead Code Elimination Regression at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102879 Richard Biener changed: What|Removed |Added Priority|P1 |P3 --- Comment #5 from Richard Biener --- There's nothing special about this bug that makes it more important that the other "DCE" regressions identified against GCC 12 like PRs 102540, 102705, 102892, 102981, 102982, 103388, 104530, 105086.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 Ever confirmed|0 |1 Summary|[12 Regression] ICE: in |[12 Regression] ICE: in |cmp_cst, at |cmp_cst, at |analyzer/svalue.cc:309 with |analyzer/svalue.cc:309 with |-fanalyzer |-fanalyzer since ||r12-2337-g33255ad3ac14e395 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-2337-g33255ad3ac14e395.
[Bug analyzer/105366] [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-25 --- Comment #1 from Martin Liška --- Started with r11-4511-gf635f0ce87d687b1.
[Bug rtl-optimization/105376] New: ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105376 Bug ID: 105376 Summary: ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 52868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52868&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -g testcase.c during RTL pass: final testcase.c: In function 'foo': testcase.c:6:1: internal compiler error: in decimal_to_decnumber, at dfp.cc:134 6 | } | ^ 0x22f0853 decimal_to_decnumber /repo/gcc-trunk/gcc/dfp.cc:134 0x22f0adf encode_decimal128(real_format const*, long*, real_value const*) /repo/gcc-trunk/gcc/dfp.cc:269 0x12e6585 real_to_target(long*, real_value const*, format_helper) /repo/gcc-trunk/gcc/real.cc:2838 0xf1d9b3 insert_float /repo/gcc-trunk/gcc/dwarf2out.cc:20173 0xf560d6 mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) /repo/gcc-trunk/gcc/dwarf2out.cc:16654 0xf5642e mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) /repo/gcc-trunk/gcc/dwarf2out.cc:16481 0xf563c9 mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) /repo/gcc-trunk/gcc/dwarf2out.cc:16470 0xf5b30a loc_descriptor /repo/gcc-trunk/gcc/dwarf2out.cc:17357 0xf5b70a dw_loc_list_1 /repo/gcc-trunk/gcc/dwarf2out.cc:17460 0xf5bc59 dw_loc_list /repo/gcc-trunk/gcc/dwarf2out.cc:17743 0xf51819 loc_list_from_tree_1 /repo/gcc-trunk/gcc/dwarf2out.cc:18939 0xf6198d loc_list_from_tree /repo/gcc-trunk/gcc/dwarf2out.cc:19642 0xf6198d add_location_or_const_value_attribute /repo/gcc-trunk/gcc/dwarf2out.cc:20861 0xf61ca7 gen_formal_parameter_die /repo/gcc-trunk/gcc/dwarf2out.cc:22966 0xf44425 gen_subprogram_die /repo/gcc-trunk/gcc/dwarf2out.cc:23978 0xf4911c gen_decl_die /repo/gcc-trunk/gcc/dwarf2out.cc:26977 0xf4a12b dwarf2out_decl /repo/gcc-trunk/gcc/dwarf2out.cc:27555 0xf4a5de dwarf2out_function_decl /repo/gcc-trunk/gcc/dwarf2out.cc:27570 0xfd16e2 rest_of_handle_final /repo/gcc-trunk/gcc/final.cc:4321 0xfd16e2 execute /repo/gcc-trunk/gcc/final.cc:4363 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ 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-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/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 --disable-bootstrap --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-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220425 (experimental) (GCC)
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #4 from Jonathan Wakely --- Ah it's noted as a DR at https://en.cppreference.com/w/cpp/thread/packaged_task#Defect_reports
[Bug rtl-optimization/105376] ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105376 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- It's there at least since GCC 4.8.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
This can (and IMHO should no matter what) be fixed in reassoc by:
--- gcc/tree-ssa-reassoc.cc.jj 2022-04-14 13:46:59.690140053 +0200
+++ gcc/tree-ssa-reassoc.cc 2022-04-25 15:34:03.811473537 +0200
@@ -2254,7 +2254,11 @@ eliminate_redundant_comparison (enum tre
BIT_AND_EXPR or BIT_IOR_EXPR was of a wider integer type,
we need to convert. */
if (!useless_type_conversion_p (TREE_TYPE (curr->op), TREE_TYPE (t)))
- t = fold_convert (TREE_TYPE (curr->op), t);
+ {
+ if (!fold_convertible_p (TREE_TYPE (curr->op), t))
+ continue;
+ t = fold_convert (TREE_TYPE (curr->op), t);
+ }
if (TREE_CODE (t) != INTEGER_CST
&& !operand_equal_p (t, curr->op, 0))
But another question is if we shouldn't actually optimize it rather than
punting out.
The reason why that happens is that while eliminate_redundant_comparison
indirectly passes the V4BImode vector type as TYPE argument, the function
doesn't actually use it and uses truth_type (V4SImode) instead.
truth_type use has been introduced in r0-119133-gae22ac3c62db451bae
but at that point the type argument didn't exist.
That has been only introduced in r10-3154-g5f487a349de62613d7fa429 .
I wonder if we can't just kill the truth_type computation and replace all uses
with type...
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1
[Bug c++/105377] New: Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Bug ID: 105377 Summary: Likely a misleading clang warning -Wc++20-attribute-extensions Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: mpolacek at gcc dot gnu.org, redi at gcc dot gnu.org Target Milestone: --- I noticed the following warning: clang++ -I/home/marxin/Programming/gcc/libcpp -I. -I/home/marxin/Programming/gcc/libcpp/../include -I/home/marxin/Programming/gcc/libcpp/include -g -O2 -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I/home/marxin/Programming/gcc/libcpp -I. -I/home/marxin/Programming/gcc/libcpp/../include -I/home/marxin/Programming/gcc/libcpp/include -fPIC -fcf-protection -c -o lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo /home/marxin/Programming/gcc/libcpp/lex.cc -std=c++17 /home/marxin/Programming/gcc/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-attribute-extensions] ATTR_LIKELY case kind::NONE: ^~~ /home/marxin/Programming/gcc/libcpp/system.h:427:25: note: expanded from macro 'ATTR_LIKELY' # define ATTR_LIKELY [[likely]] ~~^~~~
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #3 from Jakub Jelinek ---
Also, no idea where exactly to put the testcase to and what dg-* directives to
use, arm testcases is something I'm really not familiar with.
Perhaps gcc.target/arm/mve/general
and
/* { dg-do compile } */
/* { dg-require-effective-target arm_v8_1m_mve_ok } */
/* { dg-add-options arm_v8_1m_mve } */
but can -mfloat-abi=hard be just added or does it require some extra magic?
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #5 from raldone01 --- Thank you for your reply. What does that mean? Are defect reports updates for older standards? Is it meant to be available at some point in c++17?
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Yes, it is an extension, but if the compiler doesn't recognize it, it shouldn't do anything with it. So it is just fine to use it... Especially when gcc only uses it when the compiler tells it it supports it... #ifdef __has_cpp_attribute # if __has_cpp_attribute(likely) # define ATTR_LIKELY [[likely]] # elif __has_cpp_attribute(__likely__) # define ATTR_LIKELY [[__likely__]] # else # define ATTR_LIKELY # endif #else # define ATTR_LIKELY #endif
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 --- Comment #2 from Marek Polacek --- Yes, I'd prefer to keep it the way it is.
[Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:362e2a9c6297203bcf7f66bfb51dffb82b42d3b3 commit r12-8246-g362e2a9c6297203bcf7f66bfb51dffb82b42d3b3 Author: Andrew MacLeod Date: Mon Apr 25 09:56:35 2022 -0400 Retain existing range knowledge when prefilling statements. When range_of_stmt was adjusted to avoid large recursion depth, we need to intersect the calculated range whth the any known range to avoid losing info. Range_of_stmt does this, but the new prefill code missed it. PR tree-optimization/105276 gcc/ * gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Include existing global range with calculated value. gcc/testsuite/ * g++.dg/pr105276.C: New.
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- it's probably due to the combination of -pedantic and -std=c++17; what happens if you use -std=gnu++17 instead for the standard?
[Bug c/105378] New: [OpenMP][5.1] 'nowait' on 'taskwait' not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378 Bug ID: 105378 Summary: [OpenMP][5.1] 'nowait' on 'taskwait' not supported Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Just to make sure it does not get forgotten as appendix B does not make it clear. Testcase: https://github.com/SOLLVE/sollve_vv/pull/474 Currently fails with: test_task_nowait.c:32:30: error: ‘nowait’ is not valid for ‘#pragma omp taskwait’ 32 | #pragma omp taskwait nowait | ^~ and applies to all FE.
[Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Macleod --- fixed.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #4 from Christophe Lyon --- Other MVE tests are in gcc.target/arm/simd/ (eg mve-vcmp-f32.c), maybe it's best to keep them in the same place? Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since the test involves floats. Thanks for the prompt fix!
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 --- Comment #4 from Jonathan Wakely --- But we don['t want to use gnu++17 because we want the compiler to be built using portable ISO C++17. An unrecognized attribute is a portable ISO C++17 construct, it just doesn't do anything (except maybe give a warning). We could add: #ifdef __clang__ #pragma clang diagnostic ignored "-Wc++20-attribute-extensions" #endif To disable this warning, since we know we're already guarding the attribute with __has_cpp_attribute.
[Bug target/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #12 from Jakub Jelinek ---
Fixed. I think you can use if (__builtin_expect_with_probability (!b, 0, 0.5))
return -2; else return 0; if you want to override the return negative
heuristics.
Or if you use it in places where that heuristics doesn't trigger, say:
int bar (int);
int g(int i) {
return bar (i ? -2 : 0);
}
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #6 from Jonathan Wakely --- (In reply to raldone01 from comment #5) > Thank you for your reply. > What does that mean? As it says at the link in comment 4, "The following behavior-changing defect reports were applied retroactively to previously published C++ standards." > Are defect reports updates for older standards? Yes. > Is it meant to be available at some point in c++17? Yes.
[Bug middle-end/105348] Overly aggressive -Warray-bounds after conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348 --- Comment #3 from Thiago Macieira --- I understand. I'm just trying to avoid having to add code for a corner-case. People don't usually parse empty buffers, so it's usually fine to allow it to proceed and discover an EOF condition. Anyway, worked around. Feel free to close if this is too hard to fix.
[Bug c++/105353] __builtin_shufflevector with value dependent constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105353 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1ba397e9f93d3abc93a6ecbabc3d873489a6fb7f commit r12-8248-g1ba397e9f93d3abc93a6ecbabc3d873489a6fb7f Author: Marek Polacek Date: Fri Apr 22 19:40:27 2022 -0400 c++: __builtin_shufflevector with value-dep expr [PR105353] Here we issue an error from c_build_shufflevector while parsing a template because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs (except the first two arguments). It checks if any of the arguments are type-dependent, if so, we leave the processing for later, but it should also check value-dependency for the 3rd+ arguments, so as to avoid the problem above. This is not a regression -- __builtin_shufflevector was introduced in GCC 12, but it looks safe enough. PR c++/105353 gcc/cp/ChangeLog: * typeck.cc (build_x_shufflevector): Use instantiation_dependent_expression_p except for the first two arguments. gcc/testsuite/ChangeLog: * g++.dg/ext/builtin-shufflevector-3.C: New test.
[Bug c++/105353] __builtin_shufflevector with value dependent constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105353 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Fixed.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #5 from Christophe Lyon --- > Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since > the test involves floats. I was wrong and your proposal of arm_v8_1m_mve_ok looks fine (since actually there is no ICE with compiling for an FP-capable FPU)
[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 52869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52869&action=edit gcc12-pr105314.patch Untested fix.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug; I'm testing a fix.
[Bug analyzer/105366] [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug; I'm testing a fix. Seems to be the same root cause as PR105365; I'm not sure why one manifests with GCC 11 and the other doesn't.
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a5cee0480c10bafa8ed65d49e5cedca23d98d7b7 commit r12-8249-ga5cee0480c10bafa8ed65d49e5cedca23d98d7b7 Author: Jonathan Wakely Date: Mon Apr 25 14:22:41 2022 +0100 libstdc++: Add deduction guides for std::packaged_task [PR105375] This change was LWG 3117. The test is copied from 20_util/function/cons/deduction.cc libstdc++-v3/ChangeLog: PR libstdc++/105375 * include/std/future (packaged_task): Add deduction guides. * testsuite/30_threads/packaged_task/cons/deduction.cc: New test.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-testresults/2022-April/760251.html certainly shows the FAIL: gcc.target/powerpc/bswap-brw.c scan-assembler \\mxxbrw\\M even when it is r12-8242 . --with-cpu=power8 powerpc64-linux-gnu
[Bug fortran/105379] New: [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 Bug ID: 105379 Summary: [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20220417 and 20220424 : $ cat z1.f90 program p type t end type contains subroutine s1(x) class(t) :: x(3) end subroutine s2(n, x) integer :: n class(t) :: x(n) end end $ cat z2.f90 program p type t end type integer :: m = 3 contains subroutine s1(x) class(t) :: x(3) end subroutine s3(x) class(t) :: x(m) end end $ gfortran-12-20220424 -c z1.f90 f951: internal compiler error: gfc_compare_array_spec(): Array spec clobbered 0x6f15b9 gfc_report_diagnostic ../../gcc/fortran/error.cc:883 0x6f3137 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.cc:1503 0x6be47f compare_bounds ../../gcc/fortran/array.cc:971 0x6bfde3 gfc_compare_array_spec(gfc_array_spec*, gfc_array_spec*) ../../gcc/fortran/array.cc:1012 0x6ff3dc compare_components ../../gcc/fortran/interface.cc:495 0x6ff6d0 gfc_compare_derived_types(gfc_symbol*, gfc_symbol*) ../../gcc/fortran/interface.cc:678 0x834de8 gfc_copy_dt_decls_ifequal(gfc_symbol*, gfc_symbol*, bool) ../../gcc/fortran/trans-types.cc:2453 0x8342c4 gfc_get_derived_type(gfc_symbol*, int) ../../gcc/fortran/trans-types.cc:2922 0x834d18 gfc_typenode_for_spec(gfc_typespec*, int) ../../gcc/fortran/trans-types.cc:1195 0x834f78 gfc_sym_type(gfc_symbol*, bool) ../../gcc/fortran/trans-types.cc:2307 0x83344f gfc_get_function_type(gfc_symbol*, gfc_actual_arglist*, char const*) ../../gcc/fortran/trans-types.cc:3161 0x7c7424 build_function_decl ../../gcc/fortran/trans-decl.cc:2393 0x7cf3a6 gfc_create_function_decl(gfc_namespace*, bool) ../../gcc/fortran/trans-decl.cc:3102 0x7d48be gfc_generate_contained_functions ../../gcc/fortran/trans-decl.cc:5768 0x7d48be gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7586 0x75700e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75700e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a44af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/105380] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380 Bug ID: 105380 Summary: ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Something has changed between 20220306 and 20220327, relevant especially for release versions : $ cat z1.f90 program p type t(n) integer, len :: n end type type t2(m) integer, len :: m type(t(1)) :: a(m) end type type(t2(3)) :: x end $ gfortran-12-20220306 -c z1.f90 $ $ gfortran-12-20220424 -c z1.f90 z1.f90:10:3: 10 | end | 1 internal compiler error: Segmentation fault 0xccf18f crash_signal ../../gcc/toplev.cc:322 0x7c2197 wi::extended_tree<576>::get_len() const ../../gcc/tree.h:6179 0x7c2197 wi::int_traits > >::decompose(long*, unsigned int, generic_wide_int > const&) ../../gcc/wide-int.h:985 0x7c2197 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&, unsigned int) ../../gcc/wide-int.h:1034 0x7c2197 generic_wide_int >::generic_wide_int > >(generic_wide_int > const&, unsigned int) ../../gcc/wide-int.h:790 0x7c2197 bool wi::lts_p >, generic_wide_int > >(generic_wide_int > const&, generic_wide_int > const&) ../../gcc/wide-int.h:1904 0x7c2197 wi::binary_traits >, generic_wide_int >, wi::int_traits > >::precision_type, wi::int_traits > >::precision_type>::signed_predicate_result operator< >, generic_wide_int > >(generic_wide_int > const&, generic_wide_int > const&) ../../gcc/wide-int.h:3250 0x7c2197 tree_int_cst_lt(tree_node const*, tree_node const*) ../../gcc/tree.h:6335 0x7c2197 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.cc:6316 0x7efa40 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8393 0x7dc1e3 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.cc:9308 0x7efb99 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8428 0x7c6ba5 gfc_emit_parameter_debug_info ../../gcc/fortran/trans-decl.cc:5513 0x78f282 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x7d4d18 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7818 0x75700e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75700e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a44af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/105380] ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- On the other hand, test versions are affected down to r8 : (gcc configured with --enable-checking=yes) $ gfortran-12-20220424 -c z1.f90 z1.f90:10:3: 10 | end | 1 internal compiler error: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.cc:6317 0x6addd6 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.cc:8798 0x7fc3f2 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3457 0x7fc3f2 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.cc:6317 0x842b00 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8393 0x842f20 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.cc:9308 0x842c59 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8428 0x814170 gfc_emit_parameter_debug_info ../../gcc/fortran/trans-decl.cc:5513 0x7d0742 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x826bc3 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7818 0x7984ce translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x7984ce gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7e653f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.4 --- Comment #8 from Jonathan Wakely --- Fixed for GCC 12, but worth backporting to GCC 11 too.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #4 from Jakub Jelinek --- With a x86_64-linux -> powerpc64-linux cross, I can see with -mcpu=power10 -m32 --- bswap-brw.s12022-04-25 18:32:35.108799457 +0200 +++ bswap-brw.s22022-04-25 18:32:38.664750135 +0200 @@ -28,10 +28,11 @@ bswap_int_dbl: # 0 # 0 "" 2 #NO_APP - xxbrw 0,0 + mfvsrwz 9,0 + brw 9,9 + stw 9,8(1) addi 9,1,8 - xxextractuw 1,0,4 - stfiwx 0,0,9 + lfiwzx 1,0,9 addi 1,1,16 .cfi_def_cfa_offset 0 fcfid 1,1 @@ -39,6 +40,6 @@ bswap_int_dbl: .cfi_endproc .LFE1: .size bswap_int_dbl,.-bswap_int_dbl - .ident "GCC: (GNU) 12.0.1 20220310 (experimental)" + .ident "GCC: (GNU) 12.0.1 20220425 (experimental)" .gnu_attribute 4, 1 .section.note.GNU-stack,"",@progbits difference, with -m64 xxbrw is still there even with latest trunk.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- Btw. started with r12-7338-g884f77b489 if that helps.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #7 from Martin Liška --- (In reply to Martin Liška from comment #6) > Btw. started with r12-7338-g884f77b489 if that helps. Oh, it was already discovered by Jakub.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #5 from Segher Boessenkool ---
And that is what the {xfail {has_arch_pwr10 && {! has_arch_ppc64}}}
is for. Does that not work for you? Why doesn't it, it works fine here?
It would be nice if this unimportant edge case was costed better as well of
course, but it wasn't worth blocking this important regression fix on it.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #6 from Jakub Jelinek ---
Somehow that doesn't really work, in the log I see that has_arch_pwr10 is
tested but yields it is not on:
/usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ arch_pwr101791933.c
-m32 -fdiagnostics-plain-output -S -o arch_pwr101791933.s(timeout = 300)
spawn -ignore SIGHUP /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/
arch_pwr101791933.c -m32 -fdiagnostics-plain-output -S -o arch_pwr101791933.s
arch_pwr101791933.c:3:18: error: #error does not have power10 support.
compiler exited with status 1
- the -mdejagnu-cpu=power10 option from the command line isn't clearly passed
to the effective target test compilation.
If I do:
--- gcc/testsuite/gcc.target/powerpc/bswap-brw.c.jj 2022-04-22
13:36:56.136961022 +0200
+++ gcc/testsuite/gcc.target/powerpc/bswap-brw.c2022-04-25
19:16:46.528029452 +0200
@@ -17,6 +17,6 @@ bswap_int_dbl (unsigned int a)
/* Force the value to be loaded into a vector register. */
__asm__ (" # %x0" : "+wa" (b));
- /* { dg-final { scan-assembler {\mxxbrw\M} {xfail {has_arch_pwr10 && {!
has_arch_ppc64}}} } } */
+ /* { dg-final { scan-assembler {\mxxbrw\M} {xfail { ! { has_arch_ppc64 } } }
} } */
return (double) __builtin_bswap32 (b);
}
then the test passes both
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
powerpc.exp=bswap-brw.c'
(in x86_64-linux -> powerpc64-linux cross).
What is the point of has_arch_pwr10 test in there? When -mdejagnu-cpu=power10
is used, then it is power10 when it is being compiled always, no?
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #7 from Segher Boessenkool --- The test generates the expected code for all other cpus.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #8 from Jakub Jelinek --- As it uses -mdejagnu-cpu=power10, it only tests power10 code generation, nothing else.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #9 from Segher Boessenkool --- Ah, lol. Yes. But please don't change this yet, it should work thew way it is now, this should be fixed. Do you see what makes the _ARCH_PWR10 test fail on your system?
