[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #20 from Chris Clayton --- On 08/07/2022 15:02, Chris Clayton wrote: > Hi > > On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 >> >> Andrew Pinski changed: >> >>What|Removed |Added >> >> Status|UNCONFIRMED |WAITING >> Ever confirmed|0 |1 >>Last reconfirmed||2022-07-03 >> > > I some additional diagnostics (the result of a bisect) to the bugzilla report > earlier this week. The first bad commit > was 8c99e307b20. > > I've been busy since but have just checked out the first bad commit's parent > commit (54a5f478487) and built with > gcc-12-20220702. That build completed successfully. As an update, I've just tried to build the gcc-13-20220717 snapshot using a compiler built with gcc-12-20220716 snapshot. The outcome is the same set of ICEs. I've also realised this morning that I forgot to add the author of the first bad coomit from the bisect that I reported the results of. So, al...@redhat.com added as recipient of this email. Aldy - the first bad commit from the bisect was 8c99e307b20c502e55c425897fb3884ba8f05882 (Convert DOM to use Ranger rather than EVRP). It seems to be involved in some way in a batch of ICEs I see when trying to build recent gcc-13 snapshots (20220626 and later) with recent gcc-12 snapshots. I aslo get the ICEs trying to build gcc-13 with a gcc-11 or gcc-10 compiler. The diagnostics I've collected are attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > >
[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331 Thomas Koenig changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Thomas Koenig --- Would it be possible to bisect this, to see if this is a front end problem or not?
[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2
[Bug c++/106310] [12/13 Regregression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106310 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2
[Bug middle-end/106323] [Suboptimal] memcmp(s1, s2, n) == 0 expansion on AArch64 compare to llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106323 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #3 from Wilco --- (In reply to Andrew Pinski from comment #1) > GCC might be better if the first bytes are in cache but the next bytes are > not and then branch is predictable (which it might be). > > So this is much more complex than just changing this really. Neither sequence is efficient. Caches are not really relevant here, it's more about giving a wide OoO core lots of useful parallel work to do, so avoiding unnecessary instructions and branches that just slow you down. Hence 4 loads and CMP+CCMP is best.
[Bug middle-end/106314] GTY fails on virtual int but not virtual void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- GC only supports POD-like data structures, esp. proper inheritance is not supported so supporting virtual functions looks useless.
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315 Richard Biener changed: What|Removed |Added Summary|7.8% increased codesize on |[13 Regression] 7.8% |specfp 507.cactuBSSN_r |increased codesize on ||specfp 507.cactuBSSN_r Target Milestone|--- |13.0 Keywords||missed-optimization --- Comment #1 from Richard Biener --- I'd check if a non-LTO build also shows a (maybe smaller) size difference so isolation to most important TUs is easier.
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|P3 |P2 Known to work||10.3.0 Keywords||needs-bisection, ||rejects-valid Last reconfirmed||2022-07-18 --- Comment #1 from Richard Biener --- I can confirm that the branch head with the standard library from GCC 10.3 still accepts the code.
[Bug target/106324] ptrue not reused between vector instructions and predicate instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106324 Richard Biener changed: What|Removed |Added Target||aarch64 --- Comment #1 from Richard Biener --- guessing aarch64
[Bug c++/106337] New: Too many compilation errors generated with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106337 Bug ID: 106337 Summary: Too many compilation errors generated with struct Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psz2007 at foxmail dot com Target Milestone: --- My G++ compiler generated too many compilation errors while compiling the following code: -- struct x struct zv
[Bug lto/106328] Build doesn't respect -j N flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||lto
Last reconfirmed||2022-07-18
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
That's the WPA LTRANS file generation which does not use the jobserver but
parallelizes for I/O. There is --param lto-max-streaming-parallelism you
can use to limit things but it's default is 32 (but that would be per
actual parallel invoked LTO link step, so with -j8 it's 8 * 32 when there
are 8 parallel invoked link steps).
See gcc/lto/lto.{c,cc}:stream_out_partitions which indeed says
#ifdef HAVE_WORKING_FORK
...
/* Do not run more than LTO_PARALLELISM streamings
FIXME: we ignore limits on jobserver. */
if (lto_parallelism > 0 && nruns >= lto_parallelism)
{
wait_for_child ();
...
if (!cpid)
{
setproctitle ("lto1-wpa-streaming");
so "confirmed" - it doesn't honor the jobserver. Note without using
-flto=auto or -flto=jobserver it would be all serial, note the above
also does not honor a limit placed via -flto=8 I think.
[Bug lto/106328] Build doesn't respect -j N flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328 --- Comment #3 from Richard Biener --- Just to clarify, GCCs WPA stage fork()s to write out LTRANS IL object files in parallel - those processes are not controlled by make but GCC could request tokens from makes jobserver if it got a handle on a connection (which isn't trivial because make does not provide the necessary open FDs to all sibling processes it creates).
[Bug target/106338] New: RISC-V static-chain register may be clobbered by PLT stubs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338 Bug ID: 106338 Summary: RISC-V static-chain register may be clobbered by PLT stubs Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: funanzeng at gmail dot com Target Milestone: --- In commit 09cae7507d9e88f2b05cf3a9404bf181e65ccbac, Palmer ported GCC to RISC-V and t2 were chosen as the static chain register. However, when I supporting this feature in LLVM(https://reviews.llvm.org/D129106), jrtc27 pointed out that this issue. In practice, static chain parameters are only used in Go and is always used with closures, where the function pointer is already resolved. As a result, this issue may not be triggered unless a user directly calls a foreign function with a static chain parameter, and thus has not caused any problem. FYI, in a recent change to the RISC-V ABI, STO_RISCV_VARIANT_CC was added to support unknown ABI.
[Bug rtl-optimization/106210] [10/11/12/13 Regression] missing shrink wrap for simple case since r9-3594-g8d2d39587d941a40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210 Martin Liška changed: What|Removed |Added CC||segher at gcc dot gnu.org Keywords|needs-bisection | Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |missing shrink wrap for |missing shrink wrap for |simple case |simple case since ||r9-3594-g8d2d39587d941a40 --- Comment #5 from Martin Liška --- All right, then it started with r9-3594-g8d2d39587d941a40.
[Bug lto/106328] Build doesn't respect -j N flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328 --- Comment #4 from Richard Biener --- If it is possible to query the '-j=N' setting from make via the jobserver connection then it might be practical to auto-tune lto-max-streaming-parallelism to that setting at least (that's still prone to N*N sub-processes).
[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||rguenth at gcc dot gnu.org Target||x86_64-*-* --- Comment #3 from Richard Biener --- Confirmed - we get # S.0_3 = PHI <1(2), S.0_7(4)> if (S.0_3 > 2) goto ; [33.33%] else goto ; [66.67%] _1 = S.0_3 + -1; _2 = &a[_1]; __builtin_memset (_2, 32, 24); S.0_7 = S.0_3 + 1; goto ; [100.00%] but somehow we fail to see that while the first [24] is 16 byte aligned, the second is not: .L4: leaq-3(%rax,%rax,2), %rcx leaq0(,%rcx,8), %rdx leaq-56(%rsp,%rdx), %rdx movdqa .LC0(%rip), %xmm0 movaps %xmm0, (%rdx) movabsq $2314885530818453536, %rsi movq%rsi, 16(%rdx) addq$1, %rax .L3: cmpq$2, %rax jle .L4 we shouldn't have used movaps %xmm0, (%rdx) here. Probably middle-end but bisection will show.
[Bug target/106338] RISC-V static-chain register may be clobbered by PLT stubs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338 --- Comment #1 from Andrew Pinski --- I don't see how this is an issue static chain is only used for nested functions in gcc and always local functions (except maybe with LTO).
[Bug target/106338] RISC-V static-chain register may be clobbered by PLT stubs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338 --- Comment #2 from Andrew Pinski --- > static chain parameters are only used in Go This is a lie. They are used with both Ada and fortan a lot. Both heavily use nested functions.
[Bug target/106338] RISC-V static-chain register may be clobbered by PLT stubs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338 --- Comment #3 from Andreas Schwab --- I think every port is using a call-clobbered register for the static chain, and it is not part of the ABI.
[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106334 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-07-18 --- Comment #1 from Richard Biener --- Confirmed. Do we eventually ggc_free during stream-in?! Breakpoint 5, dwarf2out_register_external_die (decl=, sym=0x42c6e98 "eval.cc.eec30469", off=478) at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072 6072 gcc_checking_assert (!external_die_map->get (decl)); (gdb) p sym $4 = 0x42c6e98 "eval.cc.eec30469" (gdb) p off $5 = 478 (gdb) c Continuing. Breakpoint 5, dwarf2out_register_external_die (decl=, sym=0x42c6e98 "eval.cc.eec30469", off=455) at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072 6072 gcc_checking_assert (!external_die_map->get (decl)); (gdb) p sym $6 = 0x42c6e98 "eval.cc.eec30469" (gdb) p off $7 = 455 so we have the "same" decl (address) but with different decls. Hmm. #0 free_node (node=) at /space/rguenther/src/gcc/gcc/tree.cc:1342 #1 0x00b78e43 in unify_scc (data_in=0x42b3840, from=240, len=4, scc_entry_len=1, scc_hash=852538354) at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1769 #2 0x00b79590 in lto_read_decls (decl_data=0x768cdc60, data=0x42c66b0, resolutions=...) at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1930 and #0 dwarf2out_register_external_die ( decl=, sym=0x42c6e98 "eval.cc.eec30469", off=478) at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072 #1 0x010ec851 in lto_input_tree (ib=0x7fffd770, data_in=0x42b3840) at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1911 #2 0x010ec141 in lto_read_tree_1 (ib=0x7fffd770, data_in=0x42b3840, expr=) at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1706 #3 0x010ec3ef in lto_input_scc (ib=0x7fffd770, data_in=0x42b3840, len=0x7fffd72c, entry_len=0x7fffd728, shared_scc=true) at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1798 #4 0x00b7945f in lto_read_decls (decl_data=0x768cdc60, data=0x42c66b0, resolutions=...) at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1904 note the dwarf2out registering during WPA is just using its hashtable as temporary storage, overwriting an existing entry should be fine there. An alternative would be to delay registering until we know the node is needed or providing a hook to unregister entries when we do free_node. The issue is probably latent everywhere - interesting that it didn't pop up yet. The "cheapest solution" is to short-cut the assert when flag_wpa (it's off with release checking anyway).
[Bug middle-end/106314] GTY fails on virtual int but not virtual void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> GC only supports POD-like data structures, esp. proper inheritance is not
> supported so supporting virtual functions looks useless.
Hmmm, in that case I'll remove the GTY handling from irange. At least for
SSA_NAME_RANGE_INFO this shouldn't be a problem, because we don't stream out
irange, but an irange_storage_allocator (with trailing_wide_ints).
OTOH, I see:
struct GTY (()) ipa_jump_func
{
...
...
/* Information about value range, containing valid data only when vr_known is
true. The pointed to structure is shared betweed different jump
functions. Use ipa_set_jfunc_vr to set this field. */
value_range *m_vr;
Will this be a problem?
BTW, it'd be nice if the gengtype parser would error with an appropriate
message for attempted uses of GTY with non POD-like structures, etc.
Thanks.
[Bug target/106324] ptrue not reused between vector instructions and predicate instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106324 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-07-18 Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org Keywords||missed-optimization Status|UNCONFIRMED |NEW --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug ipa/105682] [12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682 Martin Liška changed: What|Removed |Added Summary|[12/13 Regression] Both |[12/13 Regression] Both |`-Wsuggest-attribute=pure` |`-Wsuggest-attribute=pure` |and |and |`-Wsuggest-attribute=const` |`-Wsuggest-attribute=const` |on same function since |on same function since |r10-3542-g0b92cf305dcf3438 |r12-5177-g494bdadf28d0fb35 --- Comment #5 from Martin Liška --- Oh, then it started with r12-5177-g494bdadf28d0fb35.
[Bug target/106322] i386: Wrong code at O2 level (O0 / O1 are working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-07-18 CC||marxin at gcc dot gnu.org
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Blocks||26163 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-18 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/106339] New: [13 Regression] ICE in exact_div, at poly-int.h:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106339
Bug ID: 106339
Summary: [13 Regression] ICE in exact_div, at poly-int.h:2232
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-13.0.0 20220717 snapshot (g:7bcd7f47359b903bf7a193b95d4450d9d69c60ba) ICEs
when compiling the following testcase w/ -march=armv8-a+sve -O1
-ftree-slp-vectorize -fno-tree-dse:
long int v;
void
foo (void)
{
v = 0;
v = 1;
}
% aarch64-linux-gnu-gcc-13.0.0 -march=armv8-a+sve -O1 -ftree-slp-vectorize
-fno-tree-dse -c ilufi874.c
during GIMPLE pass: slp
ilufi874.c: In function 'foo':
ilufi874.c:4:1: internal compiler error: in exact_div, at poly-int.h:2232
4 | foo (void)
| ^~~
0x7cd715 poly_int<2u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<2u, unsigned long, int>(poly_int_pod<2u, unsigned long> const&, int)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/poly-int.h:2232
0x7ce24a poly_int<2u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<2u, unsigned long, int>(poly_int_pod<2u, unsigned long> const&, int)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree.h:3631
0x7ce24a can_duplicate_and_interleave_p(vec_info*, unsigned int, tree_node*,
unsigned int*, tree_node**, tree_node**)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:413
0x11d590f vect_get_and_check_slp_defs
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:645
0x11da87a vect_build_slp_tree_2
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:2177
0x11da0c8 vect_build_slp_tree
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:1572
0x11dea05 vect_build_slp_instance
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:3076
0x11dfef5 vect_analyze_slp_instance
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:3401
0x11e3245 vect_analyze_slp(vec_info*, unsigned int)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:3434
0x11eb3b9 vect_slp_analyze_bb_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:5875
0x11eb3b9 vect_slp_region
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:5977
0x11ecdb3 vect_slp_bbs
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:6168
0x11ed18c vect_slp_function(function*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vect-slp.cc:6256
0x11f50d2 execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/tree-vectorizer.cc:1532
[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Summary|[12/13 Regression] Whole|[12/13 Regression] Whole |array assignment of empty |array assignment of empty |string segfaults with -Og |string segfaults with -Og ||since ||r12-2633-ge5e164effa30fd2b CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r12-2633-ge5e164effa30fd2b.
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 Jonathan Wakely changed: What|Removed |Added Keywords|needs-bisection | --- Comment #2 from Jonathan Wakely --- I was definitely r10-10808-g22b86cdc4d7fdd
[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106334 --- Comment #2 from Martin Liška --- Btw. started with r12-6678-g254ada46ae0f21bd.
[Bug c++/106337] Too many compilation errors generated with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106337 Jonathan Wakely changed: What|Removed |Added Version|4.9.2 |13.0 Keywords||diagnostic Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-18 --- Comment #1 from Jonathan Wakely --- Yes, but nobody cares about bugs in releases from 8 years ago. Setting version to 13.0 instead.
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 --- Comment #3 from Martin Liška --- Started with r10-10808-g22b86cdc4d7fdd.
[Bug ipa/105682] [12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682
--- Comment #6 from Jan Hubicka ---
gcc-12.1.0 (bogus warning: `caller()` has no right to be const; it calls a pure
function, and that function even contains inline assembly):
I think the conlcusion here is correct. callee has pure attribute and that
means that it has no side effects except for reading global memory. So whatever
volatile assembly does has to satisfy this.
Now since assembly is not declared as reading memory, GCC concludes that the
function has no side effects and does not read global memory and this can be
uprgraded to const.
Now as optimization goes we first realize that function is pure and only later
realize that it is also const. This could have happened with older GCC versions
as well. This triggers the duplicated warning on older compilers as well with
-Wsuggest-attribute=pure -Wsuggest-attribute=const -O2 -fno-early-inlining
:
__attribute__ ((pure)) int q(int);
__attribute__ ((pure)) int t(int a)
{
if (a)
return q(2);
}
__attribute__ ((pure)) int q(int a)
{
if (!a)
return t(1);
}
int a;
int
test()
{
return t(a);
}
I guess if we want to avoid such warnings we need to hold all the information
until the end of late ltrans optimization.
[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105676
--- Comment #3 from Jan Hubicka ---
Such code is not that obviously safe. It is possible that getval will get
inlined to some calls and not other within single function. In that case the
calling function will read and modify cache variable and will assume that these
are not changed across uninlined calls to getval.
After inlinning GCC might see something like:
if (cache == -1)
cache = do_expensive_calculation();
val = getval ();
So now the question is whether one can convince gcc to duplicate and re-order
the code into something like:
if (cache == -1)
val = getval ();
cache = do_expensive_calculation();
else
val = getval ();
which technically is valid transformation given what GCC is given and would
result in duplicatd expensive calculation. I am not sure how to make this
happen.
tracer pass may be convinced to do the duplication:
if (cache == -1)
cache = do_expensive_calculation();
val = getval ();
else
val = getval ();
but I don't think we currently have transform that will reorder val = getval()
the way I need. This does not promise we won't have in future. For example it
would be good optimizations to swap calls here:
__attribute__ ((const)) test(int);
__attribute__ ((const)) test2(int);
int ret (int a, int e)
{
int c = test2 (2);
int b = test (1);
return c + b/e;
}
since division is a long operation and would benefit from b being ready earlier
than c. It is kind of defect of our scheduler that we don't seem to do that.
I will look at the confused warning. We should not suggest pure when function
is already const and I tought we already check for that.
I think we may want extra attribute for such caching functions. Internally GCC
should make difference between "I can remove repeated calls to this function"
and "this function have no side effects".
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 --- Comment #4 from Jonathan Wakely --- The problem is that join_view still requires its _InnerView to be default-constructible, but that's a transform_view holding a non-default-constructible callable. For gcc-11 this isn't a problem because of r11-8477-ge1489a3d613b6f implementing P2328, which makes join_view uses non-propagating-cache for _M_inner. That isn't on the gcc-10 branch. I'm tempted to revert the PR 103904 backport on the branch. I was never very happy about backporting it.
[Bug sanitizer/101978] thread sanitizer false positive when condition variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
--- Comment #4 from Boris Kolpackov ---
Reproduces with GCC 11.3.0 from Debian.
There is speculation on StackOverflow that links to this bug that this is
somehow causes by holding the mutex while calling notify_all(). But in our case
we get this bogus report without holding the mutex when calling notify_all().
Here is what the relevant parts in our code look like:
{
unique_lock l (state_->mutex);
state_->finished = true;
}
state_->condv.notify_all ();
And:
unique_lock l (state_->mutex);
if (!state_->finished &&
!state_->condv.wait_for (l, tm, [state_] {return state_->finished;}))
return nullopt;
Also, in our case we get two variants of this warning: as originally reported
and the second where the mutex is supposedly already destroyed (shown below).
Replacing wait_for() with wait() makes both disappear.
WARNING: ThreadSanitizer: double lock of a mutex (pid=1881)
#0 pthread_mutex_lock
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4240
(libtsan.so.0+0x4f30a)
#1 __gthread_mutex_lock
/usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:749
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x624ff5)
#2 std::mutex::lock() /usr/include/c++/11/bits/std_mutex.h:100
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x625146)
#3 std::unique_lock::lock()
/usr/include/c++/11/bits/unique_lock.h:139
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x62c701)
#4 std::unique_lock::unique_lock(std::mutex&)
/usr/include/c++/11/bits/unique_lock.h:69
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x62c64c)
#5 operator()
/tmp/bootstrap/build2-toolchain-0.15-a.0/libbutl-0.15.0-a.0.20220714150118.f07a6606e44d/libbutl/builtin.ixx:56
(libbutl-0.15.0-a.0.f07a6606e44d.so+0x24d443)
...
Location is heap block of size 104 at 0x7b1c00017370 allocated by thread T9:
#0 operator new(unsigned long)
../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:64 (libtsan.so.0+0x8857c)
#1 async_impl
/tmp/bootstrap/build2-toolchain-0.15-a.0/libbutl-0.15.0-a.0.20220714150118.f07a6606e44d/libbutl/builtin.cxx:2191
(libbutl-0.15.0-a.0.f07a6606e44d.so+0x248ee8)
#2 async_impl
/tmp/bootstrap/build2-toolchain-0.15-a.0/libbutl-0.15.0-a.0.20220714150118.f07a6606e44d/libbutl/builtin.cxx:2205
(libbutl-0.15.0-a.0.f07a6606e44d.so+0x24db72)
#3 run_pipe
/tmp/bootstrap/build2-toolchain-0.15-a.0/build2-0.15.0-a.0.20220717074539.ecfa0f59dab6/libbuild2/script/run.cxx:2160
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x82a1ec)
#4 run_expr
/tmp/bootstrap/build2-toolchain-0.15-a.0/build2-0.15.0-a.0.20220717074539.ecfa0f59dab6/libbuild2/script/run.cxx:2492
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x82c409)
...
Mutex M810501818139374456 is already destroyed.
[Bug middle-end/106314] GTY fails on virtual int but not virtual void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
--- Comment #5 from Richard Biener ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Richard Biener from comment #3)
> > GC only supports POD-like data structures, esp. proper inheritance is not
> > supported so supporting virtual functions looks useless.
>
> Hmmm, in that case I'll remove the GTY handling from irange. At least for
> SSA_NAME_RANGE_INFO this shouldn't be a problem, because we don't stream out
> irange, but an irange_storage_allocator (with trailing_wide_ints).
>
> OTOH, I see:
>
> struct GTY (()) ipa_jump_func
> {
> ...
> ...
> /* Information about value range, containing valid data only when vr_known
> is
> true. The pointed to structure is shared betweed different jump
> functions. Use ipa_set_jfunc_vr to set this field. */
> value_range *m_vr;
>
> Will this be a problem?
Well, the GTY annotation is so GC can properly compute reachability of
GC allocated memory (and release unreachable portions). You can't simply
exempt stuff here - LTO streaming is completely unrelated to GC (but PCH
streaming is not).
> BTW, it'd be nice if the gengtype parser would error with an appropriate
> message for attempted uses of GTY with non POD-like structures, etc.
gengtype unfortunately isn't a complete C++ parser (not even close), so
C++ and GC doesn't mix well.
[Bug target/106339] [13 Regression] ICE in exact_div, at poly-int.h:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106339 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253 --- Comment #12 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:7313381d2ce44b72b4c9f70bd5670e5d78d1f631 commit r13-1730-g7313381d2ce44b72b4c9f70bd5670e5d78d1f631 Author: Richard Sandiford Date: Mon Jul 18 12:57:10 2022 +0100 arm: Replace arm_builtin_vectorized_function [PR106253] This patch extends the fix for PR106253 to AArch32. As with AArch64, we were using ACLE intrinsics to vectorise scalar built-ins, even though the two sometimes have different ECF_* flags. (That in turn is because the ACLE intrinsics should follow the instruction semantics as closely as possible, whereas the scalar built-ins follow language specs.) The patch also removes the copysignf built-in, which only existed for this purpose and wasn't a ârealâ arm_neon.h built-in. Doing this also has the side-effect of enabling vectorisation of rint and roundeven. Logically that should be a separate patch, but making it one would have meant adding a new int iterator for the original set of instructions and then removing it again when including new functions. I've restricted the bswap tests to little-endian because we end up with excessive spilling on big-endian. E.g.: sub sp, sp, #8 vstrd1, [sp] vldrd16, [sp] vrev16.8d16, d16 vstrd16, [sp] vldrd0, [sp] add sp, sp, #8 @ sp needed bx lr Similarly, the copysign tests require little-endian because on big-endian we unnecessarily load the constant from the constant pool: vldr.32 s15, .L3 vdup.32 d0, d7[1] vbsld0, d2, d1 bx lr .L3: .word -2147483648 gcc/ PR target/106253 * config/arm/arm-builtins.cc (arm_builtin_vectorized_function): Delete. * config/arm/arm-protos.h (arm_builtin_vectorized_function): Delete. * config/arm/arm.cc (TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Delete. * config/arm/arm_neon_builtins.def (copysignf): Delete. * config/arm/iterators.md (nvrint_pattern): New attribute. * config/arm/neon.md (2): New pattern. (l2): Likewise. (neon_copysignf): Rename to... (copysign3): ...this. gcc/testsuite/ PR target/106253 * gcc.target/arm/vect_unary_1.c: New test. * gcc.target/arm/vect_binary_1.c: Likewise.
[Bug target/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from rsandifo at gcc dot gnu.org --- Fixed for arm and aarch64.
[Bug target/106340] New: flag set from SVE svwhilelt intrinsic not reused in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106340
Bug ID: 106340
Summary: flag set from SVE svwhilelt intrinsic not reused in
loop
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I'm experimenting with manually writing VLA loops and trying to match the
assembly code I expect/from autovectorizer. One of the main area I can't get it
to work is when setting the loop predicate using the svwhilelt intrinsics. The
instruction it corresponds to set the flags and can be directly used to
terminate the loop. Indeed, when using the autovectorizer, this is exactly what
happens.
```
void set1(uint32_t *__restrict__ out, size_t m)
{
for (size_t i = 0; i < m; i++) {
out[i] = 1;
}
}
```
compiles to
```
cbz x1, .L1
mov x2, 0
cntwx3
whilelo p0.s, xzr, x1
mov z0.s, #1
.p2align 3,,7
.L3:
st1wz0.s, p0, [x0, x2, lsl 2]
add x2, x2, x3
whilelo p0.s, x2, x1
b.any .L3
.L1:
ret
```
(Here I believe the flag set from the loop header whilelo could also be used
for the jump but that doesn't same much in this case.)
However, no matter how I trie to replicate this using manually written code
using the sve intrinsics, there is always an additional cmp instruction
generated. The closest I can get is by replicating the structure of the
auto-vectorized loop as much as possible with,
```
void set2(uint32_t *__restrict__ out, size_t m)
{
auto svelen = svcntw();
auto v = svdup_u32(1);
if (m != 0) {
auto pg = svwhilelt_b32(0ul, m);
for (size_t i = 0; i < m; i += svelen, pg = svwhilelt_b32(i, m)) {
svst1(pg, &out[i], v);
}
}
}
```
which is compiled to
```
cbz x1, .L9
mov x2, 0
cntwx3
whilelo p0.s, xzr, x1
mov z0.s, #1
.p2align 3,,7
.L11:
st1wz0.s, p0, [x0, x2, lsl 2]
add x2, x2, x3
whilelo p0.s, x2, x1
cmp x1, x2
bhi .L11
.L9:
ret
```
which is literally the same code down to register allocation except that the
branch following the `whilelo` instruction is replaced with another comparison
and branch.
[Bug sanitizer/64234] Statically sanitized executable does not export ASan symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234 Boris Kolpackov changed: What|Removed |Added CC||boris at kolpackov dot net --- Comment #7 from Boris Kolpackov --- > But why do you want to use -static-libasan ? Just link it dynamically... Another reason is shared linking clobbers executable's RUNPATH: https://github.com/google/sanitizers/issues/1219
[Bug target/106340] flag set from SVE svwhilelt intrinsic not reused in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106340
--- Comment #1 from Yichao Yu ---
Also note that this is for code I've tweaked to match what the finally code as
much as possible. For a complete implementation of this, I expect the loop
transformation done for normal loop should move the whilelt as well so that
source code like the following would generate pretty much the same code.
```
void set3(uint32_t *__restrict__ out, size_t m)
{
auto svelen = svcntw();
auto v = svdup_u32(1);
for (size_t i = 0; i < m; i += svelen) {
auto pg = svwhilelt_b32(i, m);
svst1(pg, &out[i], v);
}
}
```
Currently, while the cmp was moved to the end of the loop body and the loop
header, the whilelt that is meant to be paired with it did not so the flag from
the whilelt instruction isn't directly usable as is in the code.
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #5 from Patrick Palka ---
P2328 constrains the default ctors of various views and iterators. Some of
these constraints just repeat what is already implicitly required by the
NSDMIs, such as default_initializable<_Vp> in transform_view. Note that GCC
already treats NSDMIs as part of the "immediate context" when synthesizing a
default constructor, such that if an NSDMI is ill-formed then the constructor
will get defined as deleted. So these constraints are redundant for GCC at
least, but IIUC this behavior is an extension that other compilers e.g. Clang
don't implement: https://godbolt.org/z/s4a7axYv7. Backporting these
constraints should be safe since for GCC they have no effect and for other
compilers they'd just make some invalid programs valid.
But P2328 also adds default ctor constraints that weren't already implicitly
required by the NSDMIs, such as default_initializable<_Fp> in transform_view.
(The corresponding data member _M_fun is always default constructible since it
uses the semiregular wrapper __box.) We shouldn't have backported _these_
constraints since they cause some views to no longer be default xible.
I think we can salvage the backport by removing the problematic constraints
added by r10-10808-g22b86cdc4d7fdd:
libstdc++-v3/include/std/ranges | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 17018a5616c..faa55ebceb7 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -518,7 +518,7 @@ namespace ranges
class single_view : public view_interface>
{
public:
- single_view() requires default_initializable<_Tp> = default;
+ single_view() = default;
constexpr explicit
single_view(const _Tp& __t)
@@ -1592,9 +1592,7 @@ namespace views
[[no_unique_address]] __detail::_CachedPosition<_Vp> _M_cached_begin;
public:
- filter_view() requires (default_initializable<_Vp>
- && default_initializable<_Pred>)
- = default;
+ filter_view() requires default_initializable<_Vp> = default;
constexpr
filter_view(_Vp __base, _Pred __pred)
@@ -1940,9 +1938,7 @@ namespace views
__detail::__box<_Fp> _M_fun;
public:
- transform_view() requires (default_initializable<_Vp>
-&& default_initializable<_Fp>)
- = default;
+ transform_view() requires default_initializable<_Vp> = default;
constexpr
transform_view(_Vp __base, _Fp __fun)
@@ -2220,9 +2216,7 @@ namespace views
__detail::__box<_Pred> _M_pred;
public:
- take_while_view() requires (default_initializable<_Vp>
- && default_initializable<_Pred>)
- = default;
+ take_while_view() requires default_initializable<_Vp> = default;
constexpr
take_while_view(_Vp base, _Pred __pred)
@@ -2389,9 +2383,7 @@ namespace views
[[no_unique_address]] __detail::_CachedPosition<_Vp> _M_cached_begin;
public:
- drop_while_view() requires (default_initializable<_Vp>
- && default_initializable<_Pred>)
- = default;
+ drop_while_view() requires default_initializable<_Vp> = default;
constexpr
drop_while_view(_Vp __base, _Pred __pred)
[Bug target/106324] ptrue not reused between vector instructions and predicate instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106324 --- Comment #3 from Yichao Yu --- Actually I just realized that the not instruction used the .d version as requested, the vector instruction didn’t….. I got it reversed in the original post……
[Bug c++/106341] New: Template argument deduction of template value parameter crashes compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106341 Bug ID: 106341 Summary: Template argument deduction of template value parameter crashes compiler Product: gcc Version: 10.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lissheidr.spam at gmail dot com Target Milestone: --- Created attachment 53313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53313&action=edit small example that reproduces the bug Description: Compiler segfaults when trying to deduce the template arguments of a template value parameter with sufficiently complex nesting. OS: Ubuntu 22.10 Failing compiler versions: 9.5.0-1ubuntu1, 10.4.0-1ubuntu1, 11.1 (x86_64 via godbolt.org) Working compiler versions: 11.3.0-4ubuntu1 and up don't seem to segfault Compiler arguments: -std=c++2a g++-10 -v: Using built-in specs. COLLECT_GCC=g++-10 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.4.0-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.4.0 (Ubuntu 10.4.0-1ubuntu1)
[Bug c++/106341] Template argument deduction of template value parameter crashes compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106341 --- Comment #1 from Liss Heidrich --- Created attachment 53314 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53314&action=edit output of gcc-10 when compiling segfault.cpp
[Bug c++/106341] Template argument deduction of template value parameter crashes compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106341 --- Comment #2 from Liss Heidrich --- Created attachment 53315 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53315&action=edit output of gcc-11 when compiling segfault.cpp (from godbolt.org)
[Bug d/103944] [12/13 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #9 from Matthias Klose --- also seen in both the current Debian and Ubuntu development releases in the gcc-12 branch and the trunk 20220717. - glibc 2.33 (Debian), 2.35 (Ubuntu) - binutils 2.39 branch configured with --enable-default-pie --enable-cet seen on amd64, aarch64, s390x
[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331 --- Comment #5 from H.J. Lu --- The memory alignment passed to __builtin_memset shouldn't be 16 bytes in this case.
[Bug target/106322] i386: Wrong code at O2 level (O0 / O1 are working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #9 from Mathieu Malaterre ---
(In reply to Andrew Pinski from comment #8)
> Does -fwrapv fix the issue?
No. This seems like the exact same symptoms:
% ./tests/mul_test
"--gtest_filter=HwyMulTestGroup/HwyMulTest.TestAllMulHigh/Emu128"
Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter = HwyMulTestGroup/HwyMulTest.TestAllMulHigh/Emu128
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from HwyMulTestGroup/HwyMulTest
[ RUN ] HwyMulTestGroup/HwyMulTest.TestAllMulHigh/Emu128
i16x8 expect [0+ ->]:
0x3FFF,0x0FFF,0x03FF,0x00FF,0x003F,0x000F,0x0003,
i16x8 actual [0+ ->]:
0xBFFF,0x0FFF,0xE400,0x00FF,0xF840,0x000F,0xFE04,
Abort at
/home/malat/highway-0.17.1~git20220711.f0a396a/hwy/tests/mul_test.cc:131:
Emu128, i16x8 lane 0 mismatch: expected '0x3FFF', got '0xBFFF'.
Technically I can also execute the `uint16` portion of the unit test and
produce a failure (so this seems to be consistent behavior with signed
counterpart):
```
HWY_NOINLINE void TestAllMulHigh() {
ForPartialVectors test;
// test(int16_t());
test(uint16_t());
}
```
And then:
```
% ./tests/mul_test
"--gtest_filter=HwyMulTestGroup/HwyMulTest.TestAllMulHigh/Emu128"
Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter = HwyMulTestGroup/HwyMulTest.TestAllMulHigh/Emu128
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from HwyMulTestGroup/HwyMulTest
[ RUN ] HwyMulTestGroup/HwyMulTest.TestAllMulHigh/Emu128
u16x8 expect [0+ ->]:
0xFFFE,0x3FFF,0x0FFF,0x03FF,0x00FF,0x003F,0x000F,
u16x8 actual [0+ ->]:
0x,0x3FFF,0xD000,0x03FF,0xF100,0x003F,0xFC10,
Abort at
/home/malat/highway-0.17.1~git20220711.f0a396a/hwy/tests/mul_test.cc:131:
Emu128, u16x8 lane 0 mismatch: expected '0xFFFE', got '0x'.
```
[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331 --- Comment #6 from H.J. Lu --- This is a latent bug. GCC 11 RTL expander generates: (insn 21 20 22 (set (mem/c:TI (reg:DI 92 [ D.3947 ]) [0 MEM [(void *)&a]+0 S16 A128]) (const_wide_int 0x20202020202020202020202020202020)) "x.f90":3:6 -1 (nil)) [(void *)&a]+0 S16 A128] doesn't look right.
[Bug target/106342] New: [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 Bug ID: 106342 Summary: [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- Compiling testsuite/gcc.dg/pr104612.c on s390x results in: # gcc -c pr104612.c -O2 pr104612.c: In function ‘foo’: pr104612.c:15:1: error: unrecognizable insn: 15 | } | ^ (insn 9 8 10 2 (set (reg:V2SF 61 [ vect__2.10 ]) (ior:V2SF (and:V2SF (subreg:V2SF (reg/v:DI 63 [ v ]) 0) (reg:V2SF 65)) (and:V2SF (not:V2SF (reg:V2SF 65)) (reg:V2SF 64 "pr104612.c":12:11 -1 (nil)) during RTL pass: vregs pr104612.c:15:1: internal compiler error: in extract_insn, at recog.cc:2791 This works with GCC 11.
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 Marek Polacek changed: What|Removed |Added Target Milestone|--- |12.2 Target||s390x-redhat-linux Host||s390x-redhat-linux Build||s390x-redhat-linux Keywords||ice-on-valid-code
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 --- Comment #1 from Marek Polacek --- gcc.dg/vect/fast-math-vect-call-1.c also ICEs like that.
[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187 Richard Earnshaw changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #26 from Richard Earnshaw --- git bisect points to commit r11-9688 resolving the issue. Before that commit the ivopts pass generates: ivtmp.761_217 = (unsigned int) &au; _222 = &bu + 4; ivtmp.767_220 = (unsigned int) _222; _225 = (unsigned int) &au; _228 = _225 + 16; [local count: 858993457]: # prephitmp_136 = PHI # prephitmp_32 = PHI # ivtmp.761_278 = PHI # ivtmp.767_218 = PHI _16 = prephitmp_32 ^ prephitmp_136; _223 = (void *) ivtmp.761_278; MEM[(unsigned int *)_223] = _16; ivtmp.761_216 = ivtmp.761_278 + 4; if (ivtmp.761_216 != _228) goto ; [75.00%] else goto ; [25.00%] [local count: 644245086]: _230 = (void *) ivtmp.761_216; pretmp_120 = MEM[(unsigned int *)_230]; _229 = (void *) ivtmp.767_218; pretmp_18 = MEM[(unsigned int *)_229]; ivtmp.767_219 = ivtmp.767_218 + 4; goto ; [100.00%] And once that patch is applied we get: ivtmp.761_217 = (unsigned int) &au; ivtmp.766_220 = (unsigned int) &bu; _223 = (unsigned int) &au; _225 = _223 + 16; [local count: 858993457]: # prephitmp_136 = PHI # prephitmp_32 = PHI # ivtmp.761_278 = PHI # ivtmp.766_218 = PHI _16 = prephitmp_32 ^ prephitmp_136; _222 = (void *) ivtmp.761_278; MEM[(unsigned int *)_222] = _16; ivtmp.761_216 = ivtmp.761_278 + 4; if (ivtmp.761_216 != _225) goto ; [75.00%] else goto ; [25.00%] The main difference being that in the 'bad' code we start with &bu + 4, while in the good code we start with &bu. I'm afraid I don't know enough about this code to take this further. Richi?
[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187 --- Comment #27 from Richard Earnshaw --- BTW, compile flags for an arm-none-eabi compiler are: cc1plus -march=armv7-a+fp -mfloat-abi=hard -O2 -quiet -mthumb -fno-short-enums -fno-exceptions -fvisibility-inlines-hidden -fmath-errno -fmerge-all-constants -fvisibility=hidden -fstack-protector-strong -std=c++11
[Bug tree-optimization/106343] New: Addition with constants is not vectorized by SLP when it includes zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343
Bug ID: 106343
Summary: Addition with constants is not vectorized by SLP when
it includes zero
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: manolis.tsamis at vrull dot eu
Target Milestone: ---
Target: aarch64
Created attachment 53316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53316&action=edit
Does not vectorize
The following test case:
void foo (uint32_t dst[8], uint8_t src1[8], uint8_t src2[8])
{
uint16_t diff_e0 = src1[0] - src2[0];
uint16_t diff_e1 = src1[1] - src2[1];
uint16_t diff_e2 = src1[2] - src2[2];
uint16_t diff_e3 = src1[3] - src2[3];
uint16_t diff_e4 = src1[4] - src2[4];
uint16_t diff_e5 = src1[5] - src2[5];
uint16_t diff_e6 = src1[6] - src2[6];
uint16_t diff_e7 = src1[7] - src2[7];
uint32_t a0 = diff_e0 + 1;
uint32_t a1 = diff_e1 + 3;
uint32_t a2 = diff_e2 + 4;
uint32_t a3 = diff_e3 + 2;
uint32_t a4 = diff_e4 + 12;
uint32_t a5 = diff_e5 + 11;
uint32_t a6 = diff_e6 + 9;
uint32_t a7 = diff_e7 + 3;
dst[0] = a0;
dst[1] = a1;
dst[2] = a2;
dst[3] = a3;
dst[4] = a4;
dst[5] = a5;
dst[6] = a6;
dst[7] = a7;
}
Produces nice vectorized code on aarch64:
ldr d2, [x2]
adrpx3, .LC0
ldr d0, [x1]
ldr q1, [x3, #:lo12:.LC0]
usubl v0.8h, v0.8b, v2.8b
uaddl v2.4s, v0.4h, v1.4h
uaddl2 v0.4s, v0.8h, v1.8h
stp q2, q0, [x0]
ret
But if any of the constants is replaced with zero instead then scalar code is
produced:
ldrbw4, [x2, 1]
ldrbw8, [x1, 1]
ldrbw3, [x2, 3]
ldrbw7, [x1, 3]
sub w8, w8, w4
ldrbw6, [x1, 4]
and w8, w8, 65535
ldrbw4, [x2, 4]
sub w7, w7, w3
ldrbw5, [x1, 5]
and w7, w7, 65535
ldrbw3, [x2, 5]
sub w6, w6, w4
ldrbw9, [x2, 6]
and w6, w6, 65535
ldrbw4, [x1, 6]
sub w5, w5, w3
ldrbw10, [x2, 7]
and w5, w5, 65535
ldrbw3, [x1, 7]
sub w4, w4, w9
ldrbw11, [x2]
and w4, w4, 65535
ldrbw9, [x1]
sub w3, w3, w10
ldrbw2, [x2, 2]
add w8, w8, 3
ldrbw10, [x1, 2]
sub w9, w9, w11
and w1, w3, 65535
and w9, w9, 65535
sub w10, w10, w2
add w3, w5, 11
add w2, w4, 9
add w7, w7, 2
add w6, w6, 12
add w1, w1, 3
add w4, w9, 1
and w5, w10, 65535
stp w4, w8, [x0]
stp w5, w7, [x0, 8]
stp w6, w3, [x0, 16]
stp w2, w1, [x0, 24]
ret
It would be possible to produce the same vectorized code as above but with zero
in the constants. If I understand correctly, the identity element of addition
is not taken into consideration in the SLP vectorizer, which could be improved.
The same happens with subtraction.
I can reproduce this in any recent version of GCC (e.g. >= 10).
Vectorized case: https://godbolt.org/z/5sbb1an89
Scalar case: https://godbolt.org/z/v8jPT9jEe
[Bug fortran/106336] BLOCK construct and host association are not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106336 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- Upon further investigation, the issue is not a host association issue as there is no host association in the program. The block construct is in the inclusive scope of the program unit. Thus, there is name association. There seems to be an issue with the standard with regards to the `data` statement in block construct. For now, closing this.
[Bug tree-optimization/106343] Addition with constants is not vectorized by SLP when it includes zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-07-18 CC||ktkachov at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target|aarch64 |aarch64, x86_64 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed, it's quite odd. x86_64 is also affected: https://godbolt.org/z/q46z3hh9Y
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343
Andrew Pinski changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1 |0
Severity|normal |enhancement
Last reconfirmed|2022-07-18 00:00:00 |
Target|aarch64, x86_64 |aarch64
Summary|Addition with constants is |SLP does not support no-op
|not vectorized by SLP when |case
|it includes zero|
--- Comment #2 from Andrew Pinski ---
Also an issue with multiply:
void foo (unsigned *__restrict dst, unsigned *__restrict src1)
{
dst[0] = src1[0] * 1;
dst[1] = src1[1] * 2;
dst[2] = src1[2] * 3;
dst[3] = src1[3] * 4;
dst[4] = src1[4] * 5;
dst[5] = src1[5] * 6;
dst[6] = src1[6] * 7;
dst[7] = src1[7] * 8;
}
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-18
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 --- Comment #3 from Andrew Pinski --- I should note that I noticed LLVM does not handle this either. Basically the following operators and values can be used: For integer: + 0 - 0 * 1 / 1 | 0 & -1 (all ones) ^ 0 For floating point (only with -ffast-math, I think sub can be used with 0 and add with -0.0 without but I am not 100% sure): + 0 - 0 * 1 / 1
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I should note that I noticed LLVM does not handle this either. > > Basically the following operators and values can be used: > For integer: > + 0 > - 0 > * 1 > / 1 > | 0 > & -1 (all ones) > ^ 0 > > For floating point (only with -ffast-math, I think sub can be used with 0 > and add with -0.0 without but I am not 100% sure): > + 0 > - 0 > * 1 > / 1 Note for the following operators can support some constants which were there instead of a calculation (note this might be harder and maybe a different bug): op cst rhs * 0 0 | -1-1 & 0 0
[Bug testsuite/106344] New: A few x86_64 tests fail with -march=x86-64-v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106344
Bug ID: 106344
Summary: A few x86_64 tests fail with -march=x86-64-v2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
The following tests fail when -march=x86-64-v2 is the default:
gcc.dg/vect/bb-slp-57.c
gcc.dg/vect/slp-21.c
gcc.dg/vect/slp-perm-9.c
gcc.target/i386/minmax-9.c
gcc.target/i386/sse2-mmx-21.c
g++.target/i386/pr98218-1.C
Can be reproduced with:
$ make check-gcc RUNTESTFLAGS='--target_board=unix\{,-march=x86-64-v2\}
vect.exp=bb-slp-57.c'
$ make check-gcc RUNTESTFLAGS='--target_board=unix\{,-march=x86-64-v2\}
vect.exp=slp-21.c'
$ make check-gcc RUNTESTFLAGS='--target_board=unix\{,-march=x86-64-v2\}
vect.exp=slp-perm-9.c'
$ make check-gcc RUNTESTFLAGS='--target_board=unix\{,-march=x86-64-v2\}
i386.exp=minmax-9.c'
$ make check-gcc RUNTESTFLAGS='--target_board=unix\{,-march=x86-64-v2\}
i386.exp=sse2-mmx-21.c'
$ make check-g++ RUNTESTFLAGS='--target_board=unix\{,-march=x86-64-v2\}
i386.exp=pr98218-1.C'
Would there be a way to amend the tests so that they don't fail with
-march=x86-64-v2?
[Bug testsuite/106345] New: Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 Bug ID: 106345 Summary: Some ppc64le tests fail with -mcpu=power9 -mtune=power9 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- A few tests fail when GCC is configured with --with-cpu-64=power9 --with-tune-64=power9: gcc.target/powerpc/lhs-3.c gcc.target/powerpc/loop_align.c gcc.target/powerpc/pr92398.p9-.c It would be nice if we could strengthen the tests to pass with -mtune=power9 -mcpu=power9 too. In detail: # gcc -O2 -mdejagnu-cpu=power7 lhs-3.c -S -mtune=power8 # grep ori lhs-3.s ori 2,2,0 but with the power9 default: # gcc -O2 -mdejagnu-cpu=power7 lhs-3.c -S # grep ori lhs-3.s # The second: # gcc loop_align.c -fdiagnostics-plain-output -O2 -mdejagnu-cpu=power7 -falign-functions=16 -fno-unroll-loops -ffat-lto-objects -fno-ident -S -o loop_align.s # grep p2align loop_align.s .p2align 4,,15 .p2align 4,,15 # gcc loop_align.c -fdiagnostics-plain-output -O2 -mdejagnu-cpu=power7 -falign-functions=16 -fno-unroll-loops -ffat-lto-objects -fno-ident -S -o loop_align.s -mtune=power8 # grep p2align loop_align.s .p2align 4,,15 .p2align 5 And the third test: # gcc pr92398.p9-.c -fdiagnostics-plain-output -O2 -mvsx -ffat-lto-objects -fno-ident -S -o pr92398.p9-.s -mtune=power8 -mcpu=power8 # grep -E '(std|not)' pr92398.p9-.s not 4,4 not 5,5 std 4,0(3) std 5,8(3) .section.note.GNU-stack,"",@progbits # gcc pr92398.p9-.c -fdiagnostics-plain-output -O2 -mvsx -ffat-lto-objects -fno-ident -S -o pr92398.p9-.s # grep -E '(std|not)' pr92398.p9-.s .section.note.GNU-stack,"",@progbits
[Bug rtl-optimization/106210] [10/11/12/13 Regression] missing shrink wrap for simple case since r9-3594-g8d2d39587d941a40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210 --- Comment #6 from Segher Boessenkool --- The prepare_shrink_wrap code handles only very limited very simple cases. After g:8d2d39587d94 there is another copy at this point (which is an *improvement*, it gives more freedom). I don't see how this trips up prepare_shrink_wrap though? Btw, for rs6000 this is no longer shrink-wrapped in GCC 6 already, long before that commit. It saves r3 in r31 then (was r9), and that makes requires_stack_frame_p return true (because that reg needs to be saved on the stack before use, being non-volatile and all).
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 Erick Ochoa changed: What|Removed |Added CC||eochoa at gcc dot gnu.org --- Comment #5 from Erick Ochoa --- (In reply to Andrew Pinski from comment #3) > I should note that I noticed LLVM does not handle this either. > > Basically the following operators and values can be used: > For integer: > + 0 > - 0 > * 1 > / 1 > | 0 > & -1 (all ones) > ^ 0 > > For floating point (only with -ffast-math, I think sub can be used with 0 > and add with -0.0 without but I am not 100% sure): > + 0 > - 0 > * 1 > / 1 I think it should be possible to also consider the bit-shifts operations: >> 0 << 0
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 --- Comment #6 from Andrew Pinski --- (In reply to Erick Ochoa from comment #5) > I think it should be possible to also consider the bit-shifts operations: > > >> 0 > << 0 Yes and rotates too.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Status|WAITING |NEW --- Comment #21 from Aldy Hernandez --- Confirmed on x86-64 with: ./configure --enable-languages=c,c++ --enable-checking=no. Interestingly, --enable-checking=release works.
[Bug tree-optimization/106346] New: Potential regression on vectorization of left shift with constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Bug ID: 106346
Summary: Potential regression on vectorization of left shift
with constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: manolis.tsamis at vrull dot eu
Target Milestone: ---
Target: aarch64
Created attachment 53317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53317&action=edit
Does not vectorize on GCC > 10.3
The following test case:
void foo (uint32_t dst[8], uint8_t src1[8], uint8_t src2[8])
{
uint16_t diff_e0 = src1[0] - src2[0];
uint16_t diff_e1 = src1[1] - src2[1];
uint16_t diff_e2 = src1[2] - src2[2];
uint16_t diff_e3 = src1[3] - src2[3];
uint16_t diff_e4 = src1[4] - src2[4];
uint16_t diff_e5 = src1[5] - src2[5];
uint16_t diff_e6 = src1[6] - src2[6];
uint16_t diff_e7 = src1[7] - src2[7];
uint32_t a0 = diff_e0 << 1;
uint32_t a1 = diff_e1 << 3;
uint32_t a2 = diff_e2 << 4;
uint32_t a3 = diff_e3 << 2;
uint32_t a4 = diff_e4 << 12;
uint32_t a5 = diff_e5 << 11;
uint32_t a6 = diff_e6 << 9;
uint32_t a7 = diff_e7 << 3;
dst[0] = a0;
dst[1] = a1;
dst[2] = a2;
dst[3] = a3;
dst[4] = a4;
dst[5] = a5;
dst[6] = a6;
dst[7] = a7;
}
Compiles at -O3 to nice vectorized code by loading the constants from memory in
GCC 10.3:
ldr d0, [x1]
adrpx3, .LC0
ldr d1, [x2]
adrpx1, .LC1
ldr q3, [x3, #:lo12:.LC0]
usubl v0.8h, v0.8b, v1.8b
ldr q2, [x1, #:lo12:.LC1]
uxtlv1.4s, v0.4h
uxtl2 v0.4s, v0.8h
sshlv1.4s, v1.4s, v3.4s
sshlv0.4s, v0.4s, v2.4s
stp q1, q0, [x0]
ret
But this has regressed in later releases, with GCC still loading the constants
from memory but also emitting a lot of scalar code before that. For example GCC
13 produces:
adrpx3, .LC0
ldrbw6, [x1, 4]
fmovd0, x6
ldrbw7, [x1]
ldr q5, [x3, #:lo12:.LC0]
fmovd1, x7
ldrbw3, [x1, 5]
ldrbw4, [x1, 1]
ldrbw8, [x2, 4]
ldrbw5, [x2, 5]
ins v0.h[1], w3
ldrbw6, [x2]
fmovd2, x8
ldrbw3, [x2, 1]
fmovd3, x6
ins v2.h[1], w5
ins v1.h[1], w4
ldrbw9, [x1, 2]
ins v3.h[1], w3
ldrbw8, [x1, 6]
ldrbw7, [x2, 2]
ldrbw6, [x2, 6]
ins v1.h[2], w9
ins v0.h[2], w8
ldrbw5, [x1, 3]
ins v3.h[2], w7
ldrbw4, [x1, 7]
ins v2.h[2], w6
ldrbw1, [x2, 7]
ldrbw3, [x2, 3]
ins v1.h[3], w5
ins v0.h[3], w4
ins v2.h[3], w1
ins v3.h[3], w3
adrpx1, .LC1
ldr q4, [x1, #:lo12:.LC1]
sub v1.4h, v1.4h, v3.4h
sub v0.4h, v0.4h, v2.4h
uxtlv1.4s, v1.4h
uxtlv0.4s, v0.4h
sshlv1.4s, v1.4s, v5.4s
sshlv0.4s, v0.4s, v4.4s
stp q1, q0, [x0]
ret
Interestingly, this happens only with left shift and not with right shift.
GCC 10.3 vs trunk comparison: https://godbolt.org/z/xWbfGdfen
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #22 from Andrew Pinski --- (In reply to Aldy Hernandez from comment #21) > Confirmed on x86-64 with: ./configure --enable-languages=c,c++ > --enable-checking=no. > > Interestingly, --enable-checking=release works. well some gcc_assert is changed based on checking. configure.ac: release)ac_assert_checking=1 ; ac_checking= ; ac_df_checking= ; ac_fold_checking= ; ac_gc_checking= ; ac_extra_checking= ; ac_gc_always_collect= ; ac_gimple_checking= ; ac_rtl_checking= ; ac_rtlflag_checking= ; ac_runtime_checking=1 ; ac_tree_checking= ; ac_valgrind_checking= ; ac_types_checking= ;; no|none)ac_assert_checking= ; ac_checking= ; ac_df_checking= ; ac_fold_checking= ; ac_gc_checking= ; ac_extra_checking= ; ac_gc_always_collect= ; ac_gimple_checking= ; ac_rtl_checking= ; ac_rtlflag_checking= ; ac_runtime_checking= ; ac_tree_checking= ; ac_valgrind_checking= ; ac_types_checking= ;; ... system.h: /* Use gcc_assert(EXPR) to test invariants. */ #if ENABLE_ASSERT_CHECKING #define gcc_assert(EXPR)\ ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) #elif (GCC_VERSION >= 4005) #define gcc_assert(EXPR)\ ((void)(UNLIKELY (!(EXPR)) ? __builtin_unreachable (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #endif #if CHECKING_P #define gcc_checking_assert(EXPR) gcc_assert (EXPR) #else /* N.B.: in release build EXPR is not evaluated. */ #define gcc_checking_assert(EXPR) ((void)(0 && (EXPR))) #endif So if there is any side effects in gcc_assert that should not be there, --enable-checking=no will actually not compile it.
[Bug target/106347] New: [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106347
Bug ID: 106347
Summary: [13 Regression] ICE in ix86_output_ssemov, at
config/i386/i386.cc:5565, or ICE in final_scan_insn_1,
at final.cc:2860 (error: could not split insn)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-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 20220717 snapshot (g:7bcd7f47359b903bf7a193b95d4450d9d69c60ba) ICEs
when compiling the following testcase w/ -O2 -fno-expensive-optimizations:
__int128 m;
int n;
__attribute__ ((noinline)) int
return_zero (void)
{
return 0;
}
void
foo (void)
{
while (m < 0)
{
if (n || return_zero ())
__builtin_trap ();
++m;
}
}
% x86_64-unknown-linux-gnu-gcc-13.0.0 -O2 -fno-expensive-optimizations -c
n75cwvsz.c
during RTL pass: final
n75cwvsz.c: In function 'foo':
n75cwvsz.c:20:1: internal compiler error: in ix86_output_ssemov, at
config/i386/i386.cc:5565
20 | }
| ^
0x7bc5e8 ix86_output_ssemov(rtx_insn*, rtx_def**)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/config/i386/i386.cc:5565
0xb34761 final_scan_insn_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2826
0xb34d0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2939
0xb34eb4 final_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:1996
0xb35a66 rest_of_handle_final
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4284
0xb35a66 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4364
2.
Changing "while (m < 0)" to "while (m < 1)" yields the following ICE instead:
n75cwvsz.c:20:1: error: could not split insn
20 | }
| ^
(insn:TI 3 57 93 5 (set (mem/c:V1TI (reg/f:DI 7 sp) [3 %sfp+-16 S16 A128])
(reg:TI 4 si [orig:84 _3 ] [84])) "n75cwvsz.c":18:7 81
{*movti_internal}
(nil))
during RTL pass: final
n75cwvsz.c:20:1: internal compiler error: in final_scan_insn_1, at
final.cc:2860
0x727cc3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/rtl-error.cc:108
0x6bc2f0 final_scan_insn_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2860
0xb34d0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2939
0xb34eb4 final_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:1996
0xb35a66 rest_of_handle_final
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4284
0xb35a66 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4364
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #23 from Chris Clayton --- On 18/07/2022 19:13, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Aldy Hernandez changed: > >What|Removed |Added > > CC||aldyh at gcc dot gnu.org > Status|WAITING |NEW > > --- Comment #21 from Aldy Hernandez --- > Confirmed on x86-64 with: ./configure --enable-languages=c,c++ > --enable-checking=no. > > Interestingly, --enable-checking=release works. > Yes, that build succeeds here too. I've had --disable-checking in the picture for at least 5 years, and it's not been a problem. I've built hundreds of gcc- snapshots using gcc- snapshots in that time. Anyway I can drop the checking option altogether because the documentation states that --enable-checking=release is the default. But I guess there is a problem that needs to be fixed albeit maybe not an urgent one. If anyone wants a fix testing, I'm more than happy to help, so just drop me an email. I'll put a comment in my rpm spec file to remind that I need to add the option back in. Thanks.
[Bug tree-optimization/106280] dom_oracle::register_transitives is expensive for deep dominator trees
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106280 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:5e47c9333df6df1aa9da861f07e68f985d7d28fb commit r13-1737-g5e47c9333df6df1aa9da861f07e68f985d7d28fb Author: Andrew MacLeod Date: Thu Jul 14 12:35:55 2022 -0400 Check if transitives need to be registered. Whenever a relation is added, register_transitive is always called. If neither operand was in a relation before, or this is not a new relation, then there is no need to register transitives. PR tree-optimization/106280 * value-relation.cc (dom_oracle::register_relation): Register transitives only when it is possible for there to be one. (dom_oracle::set_one_relation): Return NULL if this is an existing relation.
[Bug fortran/103590] ICE: find_array_spec(): Missing spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103590 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-July/058003.html
[Bug c++/106348] New: c++modules: invalid syntax accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106348 Bug ID: 106348 Summary: c++modules: invalid syntax accepted Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugzilla.gcc at me dot benboeckel.net Target Milestone: --- Source code: ```cpp export module foo; export import foo:part; // this line export constexpr int m = 0; ``` Apparently line 2 should be `export import :part;` and the syntax as shown is ill-formed. GCC doesn't reject it.
[Bug c++/106348] c++modules: invalid syntax accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106348 --- Comment #1 from Ben Boeckel --- Forgot to mention: this occurs as of commit 63d182fb86e47323ac50d9368845d712e1f7da89
[Bug c/106349] New: strlen reimplementation produces infinite loop with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106349
Bug ID: 106349
Summary: strlen reimplementation produces infinite loop with
-Os
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
Compiling a function named strlen with strlen-like body generates an infinite
loop.
$ cat bug.c
#include
size_t strlen(const char *str)
{
size_t n;
for (n = 0; *str++; n++);
return n;
}
$ m68k-elf-gcc -S bug.c -o - -Os
#NO_APP
.file "bug.c"
.text
.align 2
.globl strlen
.type strlen, @function
strlen:
jra strlen
.size strlen, .-strlen
.ident "GCC: (GNU) 12.1.0"
The only generated code is the infinite loop. That's a nonsense.
This issue doesn't occur with -O2.
[Bug tree-optimization/106349] strlen reimplementation produces infinite loop with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106349 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization --- Comment #1 from Andrew Pinski --- There are a few duplicates of this one. Basically the same optimization is also done for memcpy too.
[Bug tree-optimization/106349] strlen reimplementation produces infinite loop with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106349 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 102725. *** This bug has been marked as a duplicate of bug 102725 ***
[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725 Andrew Pinski changed: What|Removed |Added CC||vincent.riviere at freesbee dot fr --- Comment #6 from Andrew Pinski --- *** Bug 106349 has been marked as a duplicate of this bug. ***
[Bug c++/106348] c++modules: invalid syntax accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106348 Jonathan Wakely changed: What|Removed |Added Version|unknown |13.0 --- Comment #2 from Jonathan Wakely --- g:63d182fb86e47323ac50d9368845d712e1f7da89
[Bug c++/106350] New: O3 memcpy warning when prepending a length-1 string literal to a constant std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106350
Bug ID: 106350
Summary: O3 memcpy warning when prepending a length-1 string
literal to a constant std::string
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me+gccbugzilla at s5 dot pm
Target Milestone: ---
Created attachment 53318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53318&action=edit
Log produced by Compiler Explorer when using gcc (trunk)
The following code produces a warning under `-std=c++20 -O3 -Wrestrict`:
#include
std::string memcpy_bug() {
return "x" + std::string("yz");
}
(1) If `"x"` is changed to be a string literal of any length other than 1, the
warning does not occur
(2) If `std::string("yz")` is pulled out into a variable (i.e. `std::string
var("yz");` and `return "x" + var;`) the warning does not occur
(3) If the optimization mode used is O1, O2, or Os, the warning does not occur
(4) If the compiler version is downgraded to GCC 11.3, the warning does not
occur
Appending a length-1 literal does not have this issue.
Attached is the log produced by Compiler Explorer on GCC trunk commit
c70a48a8f8f6a43b35f783b5672c9a3c0a363c31.
Possibly related to . I
made the decision to submit this independently due to (2), but I don't doubt
that it's likely a duplicate.
[Bug fortran/106331] [12/13 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331 --- Comment #7 from H.J. Lu --- Breakpoint 6, expand_builtin_memset_args (dest=0x77b6f1a0, val=0x77f86978, len=0x77f86960, target=0x77da7400, mode=E_VOIDmode, orig_exp=0x77da9d38) at /export/gnu/import/git/gitlab/x86-gcc/gcc/builtins.cc:4200 4200 dest_mem = get_memory_rtx (dest, len); (gdb) call debug_tree (dest) string-flag BLK size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x77f932a0 domain pointer_to_this > public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type 0x77f93738> side-effects arg:0 arg:0 arg:0 arg:1 visited def_stmt _1 = S.0_3 + -1; version:1> x.f90:3:6 start: x.f90:3:6 finish: x.f90:3:6> x.f90:3:6 start: x.f90:3:6 finish: x.f90:3:6> x.f90:3:6 start: x.f90:3:6 finish: x.f90:3:6> (gdb) next 4201 val_mode = TYPE_MODE (unsigned_char_type_node); (gdb) call debug_rtx (dest_mem) (mem/c:BLK (reg:DI 92 [ D.4232 ]) [0 MEM [(void *)&a]+0 A128]) (gdb) Alignment on dest_mem is wrong since array reference isn't constant.
[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #8 from Alexandre Oliva ---
I'm running into some problems that are related with this PR.
First off, on i686-linux-gnu with --enable-default-pie, attr-ifunc-3.c fails to
link with e.g. binutils 2.30 (the linker in Trisquel 9), from before binutils
commit 4ec0995016801cc5d5cf13baf6e10163861e6852. The error was "relocation
R_386_GOTOFF against STT_GNU_IFUNC symbol `foo' isn't supported".
Using a binutils 2.38.50 from May 2022, it doesn't fail to link, but it fails
at runtime. The @GOTOFF relocation to the IFUNC appears to be handled
correctly only in PDEs.
I figured @GOTOFF for IFUNCs was an unreliable feature to use on x86, and
patched predicates.md:local_symbolic_operand to return !ix86_call_use_plt_p
(op) instead of true for SYMBOL_REF_LOCAL_P. That got (pun not intended)
attr-ifunc-3.c to pass, but regressed the testcases named after this PR.
I started looking into how it was supposed to work, and how it managed to work
on x86_64, and understood the reasoning of forcing into existence and using the
PLT entry as the canonical address for the IFUNC. That works for hidden
visibility, but I wondered, what if the symbol bound locally in a shared lib,
but was still visible to the main executable, i.e., protected visibility?
Alas, even on x86_64, that resolves the IFUNC to different canonical addresses.
Specifically, compiling and linking pr83782-1.c s/hidden/protected/ into a
shared library, and then compiling and linking the following main program with
this library, the function calls succeed, but the pointer compare fails:
extern void foo (void);
extern void *bar(void);
int main() {
void (*p)(void) = bar();
p();
foo();
if (p != foo)
__builtin_abort ();
}
ISTM the test has to be stricter than binding locally, it has to either be
known to be part of the main executable (-fPIE/-fpie) or known not to be
visible to other loadable modules.
As for x86, I don't see that it's prudent to use @GOTOFF for IFUNC even with
-fPIC: even if the PIE linker bug is fixed, regular PIC may be used in PIE, and
linkers since 2018 will silently misresolve the relocation. WDYT?
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2022-07-19
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Kewen Lin ---
Thanks for reporting!
For
gcc.target/powerpc/lhs-3.c AND its siblings lhs-{1,2}.c
gcc.target/powerpc/loop_align.c
, they should use (or append) dejagnu-tune since the expected asm requires the
related sched info.
But for gcc.target/powerpc/pr92398.p9-.c, it fails due to one different cause:
the case is guarded with ! has_arch_pwr9, shouldn't tested with p9 setting, but
the previous evaluation failed, see below:
is-effective-target: has_arch_pwr9 0
arch_pwr91035958.c:8: error: ISO C forbids an empty translation unit
[-Wpedantic]
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/106343] SLP does not support no-op case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343 --- Comment #7 from Richard Biener --- SLP discovery doesn't support this (and there's for sure some duplicate bug about this). Note that SLP discovery currently does a greedy search from the stores and it commits to the first "working" graph (where "working" differs from loop vs. non-loop operation), opening up more "fixup" possibilities will also open up the chance for it to de-rail more easily.
[Bug target/106346] Potential regression on vectorization of left shift with constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346 Richard Biener changed: What|Removed |Added Blocks||53947 Keywords||needs-bisection Component|tree-optimization |target --- Comment #1 from Richard Biener --- We no longer seem to handle the widening subtract but instead build up vectors from scalar widened src1/src2. "fails" with 10.4 on x86_64, works with 11.3, 12.1 and trunk there (but needs AVX2). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106347 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
