[Bug tree-optimization/95694] [9/10/11 Regression] ICE in trunc_int_for_mode, at explow.c:59 since r9-7156-g33579b59aaf02eb7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95694 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Richard Biener --- Looks really similar to PR95528.
[Bug target/95713] [10/11 Regression] ICE in emit_move_insn when converting int2 vector to short2 vector for -march=skylake-avx512 since r10-5031-g78307657cf9675bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95713 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Richard Biener --- Looks really similar to PR95528.
[Bug tree-optimization/95694] [9/10/11 Regression] ICE in trunc_int_for_mode, at explow.c:59 since r9-7156-g33579b59aaf02eb7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95694 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #3) > Looks really similar to PR95528. Sorry - wrong bug.
[Bug target/95713] [10/11 Regression] ICE in emit_move_insn when converting int2 vector to short2 vector for -march=skylake-avx512 since r10-5031-g78307657cf9675bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95713 Richard Biener changed: What|Removed |Added Target|i?86-*-*|x86_64-*-* i?86-*-* Target Milestone|--- |10.2 CC||hjl.tools at gmail dot com, ||kyukhin at gcc dot gnu.org --- Comment #2 from Richard Biener --- So the expansion of b_4 = VEC_PACK_TRUNC_EXPR <_2, _7>; with two V1SI operands results in a DImode rtx (reg:DI 93) but RTL expansion wants to see it in (reg:SI 84) (that is b). But the simplistic code doing that doesn't work (obviously): temp = force_operand (temp, target); if (temp != target) emit_move_insn (target, temp); I guess the expansion of VEC_PACK_TRUNC_EXPR is "wrong". We do have CODE_FOR_vec_pack_trunc_si but that maps to (define_expand "vec_pack_trunc_" [(set (match_operand: 0 "register_operand") (ior: (ashift: (zero_extend: (match_operand:SWI24 2 "register_operand")) (match_dup 3)) (zero_extend: (match_operand:SWI24 1 "register_operand"] "TARGET_AVX512BW" where expand_binop_directly does 1098 if (binoptab == vec_pack_trunc_optab ... 1106 /* The mode of the result is different then the mode of the 1107 arguments. */ 1108 tmp_mode = insn_data[(int) icode].operand[0].mode; and tmp_mode ends up as DImode. Shouldn't the pattern use HALFMASKMODE? Are those patterns supposed to only trigger for VECTOR_BOOLEAN and not "generic" vectors mapping to integer modes?
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #40 from Martin Liška --- (In reply to qinzhao from comment #39) > (In reply to Martin Liška from comment #38) > > Created attachment 48738 [details] > > Patch candidate v2 > I have added this patch to my private gcc 8 with some change, works fine > with the small testing case, and fixed the bug I reported in comment #36. Great! Please report collected statistics for the patch and I'm also curious about a parallel gcov-tool merging? > > > > There's a properly tested patch that supports all operations. > > Please apply also pending patch: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548206.html > > do I need to apply this as well in order to get the data from the real > application? (note I need to apply the patch to gcc 8, this patch is not > easy to be applied to gcc 8). This patch is already applied to master and it does not effect GCC 8 branch.
[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706 --- Comment #1 from Richard Biener --- Why on earth does it show the error on line 6 on powerpc?!
[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4 Priority|P3 |P4
[Bug target/95713] [10/11 Regression] ICE in emit_move_insn when converting int2 vector to short2 vector for -march=skylake-avx512 since r10-5031-g78307657cf9675bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95713 Martin Liška changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10/11 Regression] ICE in |emit_move_insn when |emit_move_insn when |converting int2 vector to |converting int2 vector to |short2 vector for |short2 vector for |-march=skylake-avx512 -m32 |-march=skylake-avx512 since ||r10-5031-g78307657cf9675bc Status|UNCONFIRMED |NEW Known to fail||10.1.0, 11.0 Known to work||9.3.0 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Last reconfirmed||2020-06-17 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- -m32 is not necessary, started with r10-5031-g78307657cf9675bc
[Bug fortran/95708] [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95708 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug c/95699] __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699 --- Comment #4 from Richard Biener --- I'm inclined to close as WONTFIX or INVALID. There are several other PRs which show "surprising" behavior with respect to __builtin_constant_p and jump threading.
[Bug rtl-optimization/95696] regrename creates overlapping register allocations for vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696 --- Comment #2 from Richard Biener --- Please send patches to gcc-patc...@gcc.gnu.org
[Bug inline-asm/95692] PPC64, suspicious store in front of inline assembly section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95692 --- Comment #2 from Mark Allen --- Hi, thanks for the input. I was figuring gcc should see the inline assembly modifying r2 and any function call out of intercept_munmap() would be doing the logical equivalent of saving the current r2, calling something where a different r2 might be used, then upon return restoring r2 to whatever it was when it left intercept_munmap(). But it sounds like you're saying gcc should be the exclusive manager of r2. And I get that the activity of making a function call isn't always going to be as linear as "save current r2, set r2 for whatever new context it's calling into, restore r2". I'm open to other solutions. For most alternatives I can think of, I can at least imagine potential gcc behavior that would conflict with us hacking r2, which I expect is why you're suggesting doing nothing but our own assembly from intercept_munmap() downward. That would be rough though, we'd definitely like to be able to call other functions from intercept_munmap(). The problem starts when we turn munmap into a branch into intercept_munmap. At that point r2 would have been set up as valid for munmap() but then we branched into intercept_munmap() which presumably needs its own r2. So far the best hack I can see is to put it all in the initial branch. Eg overwrite munmap not just with a branch to intercept_munmap, but replace r2 at that level (rather than at the start of intercept_munmap). That essentially puts both of the things that hack the state into the same location, after which the state is consistent for gcc to continue doing whatever it wants. I'm getting the impression this isn't going to receive a blessing as a "good" solution though. Any other ideas for a "least bad" solution if we want to be able to make function calls into other gcc-compiled functions from inside intercept_munmap()?
[Bug testsuite/95716] New: g++.dg/ext/pr85503.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95716 Bug ID: 95716 Summary: g++.dg/ext/pr85503.C fails Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:92bed036098928cd4659c8990e14cf7ad040e0c2, r11-1350 Note: I only saw this on powerpc64 LE systems, not BE. Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -O2 -mvsx -S -o pr85503.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -O2 -mvsx -S -o pr85503.s /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C: In instantiation of 'struct ad > >': /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C:58:33: required from 'class bf > >' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C:121:32: required from 'class ap > >' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C:201:41: required from here /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C:200:8: error: 'typedef class ai ai::cv' is private within this context /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C:141:14: note: declared private here compiler exited with status 1 Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../ exceptions_enabled912718.cc-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o exceptions_enabled912718.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../ exceptions_enabled912718.cc -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -S -o exceptions_enabled912718.s FAIL: g++.dg/ext/pr85503.C -std=gnu++14 (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C:200:8: error: 'typedef class ai ai::cv' is private within this context Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/g++.dg/ext/pr85503.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknow
[Bug target/95488] Suboptimal multiplication codegen for v16qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95488 --- Comment #9 from Hongtao.liu --- (In reply to H.J. Lu from comment #8) > -march=skylake-avx512 gave: > > [hjl@gnu-cfl-2 gcc]$ > /export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc > -B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ > /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx512bw- > pr95488-1.c -march=skylake-avx512 -fno-diagnostics-show-caret > -fno-diagnostics-show-line-numbers -fdiagnostics-color=never > -fdiagnostics-urls=never -O2 -ffat-lto-objects -fno-ident -S -o > avx512bw-pr95488-1.s > [hjl@gnu-cfl-2 gcc]$ cat avx512bw-pr95488-1.s > .file "avx512bw-pr95488-1.c" > .text > .p2align 4 > .globl mul_512 > .type mul_512, @function > mul_512: > .LFB0: > .cfi_startproc > vpunpcklbw %ymm0, %ymm0, %ymm3 > vpunpcklbw %ymm1, %ymm1, %ymm2 > vpunpckhbw %ymm0, %ymm0, %ymm0 > vpunpckhbw %ymm1, %ymm1, %ymm1 > vpmullw %ymm3, %ymm2, %ymm2 > vpmullw %ymm0, %ymm1, %ymm1 > vpshufb .LC0(%rip), %ymm2, %ymm0 > vpshufb .LC1(%rip), %ymm1, %ymm1 > vpor%ymm1, %ymm0, %ymm0 > ret > .cfi_endproc > .LFE0: > .size mul_512, .-mul_512 > .p2align 4 > .globl umul_512 > .type umul_512, @function > umul_512: > .LFB1: > .cfi_startproc > vpunpcklbw %ymm0, %ymm0, %ymm3 > vpunpcklbw %ymm1, %ymm1, %ymm2 > vpunpckhbw %ymm0, %ymm0, %ymm0 > vpunpckhbw %ymm1, %ymm1, %ymm1 > vpmullw %ymm3, %ymm2, %ymm2 > vpmullw %ymm0, %ymm1, %ymm1 > vpshufb .LC0(%rip), %ymm2, %ymm0 > vpshufb .LC1(%rip), %ymm1, %ymm1 > vpor%ymm1, %ymm0, %ymm0 > ret > .cfi_endproc > .LFE1: > .size umul_512, .-umul_512 It's on purpose, maybe I'll add -mprefer-vector-with=512 to testcase. 19498 /* Not generate zmm instruction when prefer 128/256 bit vector width. */ 19499 if (qimode == V32QImode 19500 && (TARGET_PREFER_AVX128 || TARGET_PREFER_AVX256)) 19501return false;
[Bug fortran/95708] [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95708
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-06-16
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Built and tested against submitted code. Not regression tested.
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 280157)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -2733,7 +2733,8 @@ add_functions (void)
make_generic ("null", GFC_ISYM_NULL, GFC_STD_F95);
- add_sym_2 ("num_images", GFC_ISYM_NUM_IMAGES, CLASS_INQUIRY, ACTUAL_NO,
+ add_sym_2 ("num_images", GFC_ISYM_NUM_IMAGES, CLASS_TRANSFORMATIONAL,
+ACTUAL_NO,
BT_INTEGER, di, GFC_STD_F2008,
gfc_check_num_images, gfc_simplify_num_images, NULL,
dist, BT_INTEGER, di, OPTIONAL,
@@ -3174,7 +3175,7 @@ add_functions (void)
make_generic ("tanh", GFC_ISYM_TANH, GFC_STD_F77);
add_sym_1 ("team_number", GFC_ISYM_TEAM_NUMBER, CLASS_TRANSFORMATIONAL,
-ACTUAL_YES, BT_INTEGER, di, GFC_STD_F2018,
+ACTUAL_NO, BT_INTEGER, di, GFC_STD_F2018,
gfc_check_team_number, NULL, gfc_resolve_team_number,
team, BT_DERIVED, di, OPTIONAL);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -12937,6 +12937,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
{
if (arg->sym
&& arg->sym->ts.type == BT_DERIVED
+ && arg->sym->ts.u.derived
&& !arg->sym->ts.u.derived->attr.use_assoc
&& !gfc_check_symbol_access (arg->sym->ts.u.derived)
&& !gfc_notify_std (GFC_STD_F2003, "%qs is of a PRIVATE type "
[Bug middle-end/94895] ICE in expand_block_tm, at trans-mem.c:2643
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94895 Nicholas Krause changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #1 from Nicholas Krause --- Confirmed however seems to be latent as it seems to be hitting: case GIMPLE_ASM: gcc_unreachable (); in expand_block_tm and the commit mentioned is touching coroutines.
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #6 from Jeffrey A. Law --- That's an indication that something has tried to do an out of bounds read on a VEC object. The call chain points back to the initial quick_grow of an auto_vec from test_vector_cst_patterns -- which is wildly surprising. In fact if it were that broken I would fully expect other configurations, including x86_64 to be failing miserably. We're not seeing that. I would also expect that we could see the failure with a cross compiler, but that seems to be working fine as well. There's a nonzero chance this is actually a bug in the bootstrap compiler, particularly if it's happening in the stage1 build.
[Bug c/95715] __atomic_fetch_add accepts nonsense arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95715 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-06-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- We also accept this, adding two void* pointer together: void* i = 0; void* p = 0; void* r = __atomic_fetch_add(&i, &p, __ATOMIC_SEQ_CST); The second argument should be ptrdiff_t. Or adding a double* to an int*: double* i = 0; int* p = 0; void* r = __atomic_fetch_add(&i, &p, __ATOMIC_SEQ_CST);
[Bug c/95378] __atomic_load will write to objects of cv-qualified types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #5 from Jonathan Wakely --- Patch posted for review: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548283.html
[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d4b0f996fc497fba8724960107c3b52d3011c117 commit r11-1408-gd4b0f996fc497fba8724960107c3b52d3011c117 Author: Jonathan Wakely Date: Tue Jun 16 23:14:23 2020 +0100 middle-end: Add another testcase for PR 95493 This was reported on the gcc-help mailing list. The regression started with r10-589 and was fixed by r11-963. gcc/testsuite/ChangeLog: * g++.dg/torture/pr95493-1.C: New test.
[Bug c/95715] New: __atomic_fetch_add accepts nonsense arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95715 Bug ID: 95715 Summary: __atomic_fetch_add accepts nonsense arguments Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- gcc and g++ happily compiles this nonsense: int i = 0; void* p = 0; int r = __atomic_fetch_add(&i, &p, __ATOMIC_SEQ_CST); What does it mean to add a void* to an int? Clang diagnoses it correctly: ae.cc:3:32: error: cannot initialize a parameter of type 'int' with an rvalue of type 'void **' int r = __atomic_fetch_add(&i, &p, __ATOMIC_SEQ_CST); ^~ 1 error generated. And EDG mentions an unsigned int but at least rejects it: "ae.cc", line 3: error: argument of type "void **" is incompatible with parameter of type "unsigned int" int r = __atomic_fetch_add(&i, &p, __ATOMIC_SEQ_CST); ^ 1 error detected in the compilation of "ae.cc".
[Bug c/95714] New: Poor locations for errors in calls to __atomic built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95714
Bug ID: 95714
Summary: Poor locations for errors in calls to __atomic
built-ins
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
int main()
{
char c;
int i;
__atomic_load(&c, &i, __ATOMIC_SEQ_CST);
}
The C compiler says:
ab.cc: In function 'main':
ab.cc:5:3: error: size mismatch in argument 2 of '__atomic_load'
5 | __atomic_load(&c, &i, __ATOMIC_SEQ_CST);
| ^
and the C++ compiler says:
ab.cc: In function 'int main()':
ab.cc:5:41: error: size mismatch in argument 2 of '__atomic_load'
5 | __atomic_load(&c, &i, __ATOMIC_SEQ_CST);
| ^
Both are poor. Instead of saying "argument 2" and highlighting the function
name or the end of the argument list, we should highlight the relevant
argument:
ab.cc: In function 'main':
ab.cc:5:3: error: size mismatch in argument 2 of '__atomic_load'
5 | __atomic_load(&c, &i, __ATOMIC_SEQ_CST);
| ^~
Even better would be:
ab.cc: In function 'main':
ab.cc:5:3: error: size mismatch in argument 2 of '__atomic_load'
5 | __atomic_load(&c, &i, __ATOMIC_SEQ_CST);
| ^~ ^~
| | |
| | int*
| char*
[Bug libstdc++/95282] atomic::load in C++20 calls __atomic_load with a pointer-to-const as the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95282 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e40b11a91cb345db1324c3cb8f75b01e28056693 commit r11-1401-ge40b11a91cb345db1324c3cb8f75b01e28056693 Author: Jonathan Wakely Date: Tue Jun 16 22:34:55 2020 +0100 libstdc++: Strip cv-qualifiers in std::atomic (PR 95282) This improves the previous fix for PR 95282, and extends it to also apply to the exchange function (which has a similar problem and would become ill-formed with my proposed fix for PR 95378). PR libstdc++/95282 * include/bits/atomic_base.h (__atomic_impl::load): Use the _Val alias instead of deducing _Tp as an unqualified type. (__atomic_impl::exchange): Use the _Val alias to remove volatile from the reinterpret_cast result type.
[Bug c/95378] __atomic_load will write to objects of cv-qualified types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e40b11a91cb345db1324c3cb8f75b01e28056693 commit r11-1401-ge40b11a91cb345db1324c3cb8f75b01e28056693 Author: Jonathan Wakely Date: Tue Jun 16 22:34:55 2020 +0100 libstdc++: Strip cv-qualifiers in std::atomic (PR 95282) This improves the previous fix for PR 95282, and extends it to also apply to the exchange function (which has a similar problem and would become ill-formed with my proposed fix for PR 95378). PR libstdc++/95282 * include/bits/atomic_base.h (__atomic_impl::load): Use the _Val alias instead of deducing _Tp as an unqualified type. (__atomic_impl::exchange): Use the _Val alias to remove volatile from the reinterpret_cast result type.
[Bug c++/95711] namespace alias fails inside coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95711 --- Comment #1 from Alejandro --- When I said "It essentially happens when any namespace alias is defined inside a lambda" I meant inside a coroutine
[Bug fortran/95707] ICE in finish_equivalences, at fortran/trans-common.c:1319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95707 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-06-16 Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- The ICE is fixed by the patch: diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index c12a8bef277..836e0b3063d 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -1677,8 +1677,8 @@ typedef struct gfc_common_head char use_assoc, saved, threadprivate; unsigned char omp_declare_target : 1; unsigned char omp_declare_target_link : 1; - /* Provide sufficient space to hold "symbol.eq.1234567890". */ - char name[GFC_MAX_SYMBOL_LEN + 1 + 14]; + /* Provide sufficient space to hold "symbol.symbol.eq.1234567890". */ + char name[2*GFC_MAX_SYMBOL_LEN + 1 + 14 + 1]; struct gfc_symbol *head; const char* binding_label; int is_bind_c; However, I then get a possibly unrelated error: pr95707.f90:8:73: 8 | n2345678901234567890123456789012345678901234567890123456789_123 | 1 Warning: Named COMMON block 'm2345678901234567890123456789012345678901234567890123456789_123.n2345678901234567890123456789012345678901234567890123456789_123.eq.1' at (1) shall be of the same size as elsewhere (24 vs 32 bytes)
[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #13 from George R. Goffe --- Hi, I see that I forgot to mention that the failure generated above was made with the "latest" gcc in the repo. revision at 280157
[Bug c/95378] __atomic_load will write to objects of cv-qualified types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378 --- Comment #3 from Jonathan Wakely --- GCC correctly refuses to write through const pointers for __atomic_test_and_set, __atomic_clear, and all of __atomic_fetch_op and __atomic_op_fetch.
[Bug rtl-optimization/95713] New: [10/11 Regression] ICE in emit_move_insn when converting int2 vector to short2 vector for -march=skylake-avx512 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95713
Bug ID: 95713
Summary: [10/11 Regression] ICE in emit_move_insn when
converting int2 vector to short2 vector for
-march=skylake-avx512 -m32
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: i?86-*-*
Compile the following testcase with `-O1 -march=skylake-avx512 -m32` (cf.
https://godbolt.org/z/FASxSm):
using int2 [[gnu::vector_size(8)]] = int;
using short2 [[gnu::vector_size(4)]] = short;
void f(short2);
void g(int2 a)
{
short2 b{short(a[0]), short(a[1])};
f(4 > b);
}
Resulting Output:
during RTL pass: expand
: In function 'void g(int2)':
:7:38: internal compiler error: in emit_move_insn, at expr.c:3815
7 | short2 b{short(a[0]), short(a[1])};
| ^
[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 --- Comment #12 from George R. Goffe --- Hi, I am seeing a failure in stream_out_histogram_value building the last release of python 2.x ( 2.7.18). I just posted the preprocessed c code for this problem. Here is the failing command and following output: /tools/python/Python-2.7.18# gcc -S --save-temps -pthread -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -fprofile-use -fprofile-correction -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Objects/abstract.o Objects/abstract.c during IPA pass: fnsummary Objects/abstract.c:3124:1: internal compiler error: in stream_out_histogram_value, at value-prof.c:336 3124 | } | ^ 0x70b9a4 stream_out_histogram_value(output_block*, histogram_value_t*) ../../gcc/gcc/value-prof.c:336 0x16170b0 output_gimple_stmt ../../gcc/gcc/gimple-streamer-out.c:196 0x16170b0 output_bb(output_block*, basic_block_def*, function*) ../../gcc/gcc/gimple-streamer-out.c:231 0xbfa9b4 output_function ../../gcc/gcc/lto-streamer-out.c:2198 0xbfa9b4 lto_output() ../../gcc/gcc/lto-streamer-out.c:2530 0xc91241 write_lto ../../gcc/gcc/passes.c:2612 0xc91241 ipa_write_summaries_1 ../../gcc/gcc/passes.c:2676 0xc91241 ipa_write_summaries() ../../gcc/gcc/passes.c:2731 0x9230ab ipa_passes ../../gcc/gcc/cgraphunit.c:2650 0x9230ab symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2737 0x924d3c symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2717 0x924d3c symbol_table::finalize_compilation_unit() ../../gcc/gcc/cgraphunit.c:2984
[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 George R. Goffe changed: What|Removed |Added CC||grgoffe at yahoo dot com --- Comment #11 from George R. Goffe --- Created attachment 48747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48747&action=edit preprocessed abstract.c produced by -S --save-temps gcc flag
[Bug fortran/95688] ICE in gfc_get_string, at fortran/iresolve.c:70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95688 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Patch posted for review: https://gcc.gnu.org/pipermail/fortran/2020-June/054534.html
[Bug c++/95568] No CTAD with list initialization within requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95568 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.2 Last reconfirmed||2020-06-16 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c++/95678] [9 Regression] ICE in dependent_type_p, at cp/pt.c:25610
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95678 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- This should be fixed now.
[Bug c++/95678] [9 Regression] ICE in dependent_type_p, at cp/pt.c:25610
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95678 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d9867034e033c08fdabaebfe2f0914d7d9bb25c6 commit r9-8680-gd9867034e033c08fdabaebfe2f0914d7d9bb25c6 Author: Patrick Palka Date: Tue Jun 16 12:16:02 2020 -0400 c++: zero_init_expr_p of dependent expression [PR95678] gcc/cp/ChangeLog: PR c++/95678 * tree.c (zero_init_expr_p): Use uses_template_parms instead of dependent_type_p. gcc/testsuite/ChangeLog: PR c++/95678 * g++.dg/cpp0x/dependent3.C: New test. (cherry picked from commit 9a453da5cac7b6610cd342a7bea256acba5e61e1)
[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712
Andrew Pinski changed:
What|Removed |Added
Target|s390x-linux-gnu |
Host|s390x-linux-gnu |
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Andrew Pinski ---
This is what I do:
${PMAKE} all-gas all-binutils all-ld || return 1
make install-gas install-ld install-binutils || return 1
# glibc will provide ssp as it is new enough
gcc_cv_libc_provides_ssp=yes ${PMAKE} configure-gcc || return 1
${PMAKE} all-gcc all-target-libgcc || return 1
make install-gcc install-target-libgcc || return 1
I don't trust buildroot to do the right thing.
[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #4 from Alexander Egorenkov --- I also have the same issue with gcc 8.4.0
[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #3 from Alexander Egorenkov --- The config.log of configure-target-libgcc says: ... build/host-gcc-initial-9.3.0/build/./gcc/xgcc: No such file or directory
[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260 --- Comment #15 from Alexander Egorenkov --- (In reply to Alexander Egorenkov from comment #14) > The config.log of configure-target-libgcc says: > /home/egorenar/Repositories/buildroot/output/s390x-syzkaller/build/host-gcc- > initial-9.3.0/libgcc/configure: line 3504: > /home/egorenar/Repositories/buildroot/output/s390x-syzkaller/build/host-gcc- > initial-9.3.0/build/./gcc/xgcc: No such file or directory Sorry, please ignore the comment, i misstyped.
[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #2 from Alexander Egorenkov --- Created attachment 48746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48746&action=edit config.log for configure-target-libgcc gcc 9.3.0 Sorry attached gcc 8.4.0 log previosuly, but the same issue for gcc 9.3.0
[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58260 Alexander Egorenkov changed: What|Removed |Added CC||egorenar at linux dot ibm.com --- Comment #14 from Alexander Egorenkov --- The config.log of configure-target-libgcc says: /home/egorenar/Repositories/buildroot/output/s390x-syzkaller/build/host-gcc-initial-9.3.0/libgcc/configure: line 3504: /home/egorenar/Repositories/buildroot/output/s390x-syzkaller/build/host-gcc-initial-9.3.0/build/./gcc/xgcc: No such file or directory
[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #1 from Alexander Egorenkov --- Created attachment 48745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48745&action=edit config.log for configure-target-libgcc
[Bug libgcc/95712] New: configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 Bug ID: 95712 Summary: configure-target-libgcc fails on s390x target because xgcc is not being built Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: egorenar at linux dot ibm.com Target Milestone: --- Created attachment 48744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48744&action=edit Console output Hi all, i'm trying to build buildroot on s390x machine for s390x machine and the toolchain build step fails. I attached the build.log and the config.log of the failing target configure-target-libgcc. It seems that xgcc is not being built prior to configuring the target configure-target-libgcc. When i build on host x86_64 for s390x target then everything works with the same configuration. Regards
[Bug c++/95711] New: namespace alias fails inside coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95711
Bug ID: 95711
Summary: namespace alias fails inside coroutine
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alejandromagic at hotmail dot com
Target Milestone: ---
Created attachment 48743
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48743&action=edit
Preprocessed file
The following codes triggers a "Compiler internal Error":
namespace A
{
}
generator parse()
{
namespace B = A;
co_yield 1;
}
Where generator is just any generator implementation I've tried (I don't
think it have nothing to do with its actual implementation anyway, so I'm
providing the simplest working generator in the attached files). It essentially
happens when any namespace alias is defined inside a lambda. As an attachment I
provide the preprocessed file, although I guess the source should be enough (I
only #include coroutine for obvious reasons).
The command used to compile is:
gcc -v -save-temps --std=c++20 -fcoroutines main.cpp
The system is:
Linux parrot 4.14.0-parrot13-amd64 #1 SMP Parrot 4.14.13-1parrot13 (2018-01-21)
x86_64 GNU/Linux
The output of the compiler (in case it is needed):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib
--enable-languages=c,c++,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200507 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic
-march=x86-64 -std=c++2a -fcoroutines -fpch-preprocess -o main.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux-gnu
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main
-std=c++2a -version -fcoroutines -o main.s
GNU C++17 (GCC) version 11.0.0 20200507 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200507 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++17 (GCC) version 11.0.0 20200507 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200507 (experimental), GMP version
6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 879e7d5007757f82203f25a489026164
main.cpp: In function ‘generator parse()’:
main.cpp:60:1: internal compiler error: tree check: expected var_decl or
parm_decl or result_decl, have namespace_decl in register_local_var_uses, at
cp/coroutines.cc:3440
60 | }
| ^
0x7df6ea tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9731
0x61a5d5 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/gcc/tree.h:3334
0x61a5d5 register_local_var_uses
../../gcc/gcc/cp/coroutines.cc:3440
0x12ab9fa walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/gcc/tree.c:12001
0x8e44e6 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
../../gcc/gcc/cp/coroutines.cc:3815
0x92ebf1 finish_function(bool)
../../gcc/gcc/cp/decl.c:16921
0x9d8427 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:29013
0x9d9409 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:28926
0x9d9409 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20675
0x9ba1d2 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13739
0x9e33d2 cp_pa
[Bug c/95699] __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Yeah, in the GCC9 case, there is jump threading of the __builtin_constant_p, so
it is essentially
if (r < 0x8000)
printf ("%d\n", __builtin_constant_p (0) && 0 < 1);
else
printf ("%d\n", __builtin_constant_p (r * r) && r * r < 1);
where in the first printf __builtin_constant_p evaluates to 1 and 0 < 1 too,
while in the second one __builtin_constant_p (r * r) evaluates to 0.
In GCC 10, this just doesn't happen, since
r10-3106-g46dfa8ad6c18feb45d35734eae38798edb7c38cd aka PR90387 fix.
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #8) > I still don't understand why propagating one SSA_NAME for another is causing > headaches later though. TBH, I don't either. When I compile the .c test in this PR with the following options: -O2 -fno-tree-scev-cprop -fdisable-tree-ccp1 -fdisable-tree-ccp2 -fdisable-tree-copyprop1 -fdisable-tree-evrp -fdisable-tree-vrp1 -fdisable-tree-ccp1 -fdisable-tree-ccp2 -fdisable-tree-ccp3 ...I still get an ICE, but there is no change in the IL between trunk without the offending patch, and with the patch that broke the test. This would indicate that there is some on-the-side structure that is being altered by the phi argument propagation. I did notice that the IL *does* change in the middle of one of the copyprop (or ccp?) passes, but it gets cleaned up to whatever was there before. Later in SCEV, we ICE while trying to look at the SSA_NAME_DEF_STMT of an SSA which no longer exists in the IL. This happens in chrec_contains_symbols_defined_in_loop(). A wild guess is that the loop info is getting mucked up somehow. I can investigate more deeply if desired, but since this was a silly typo, I'm gonna leave it alone for now. Closing as fixed in mainline.
[Bug fortran/95710] New: ICE in gfc_type_is_extensible, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710 Bug ID: 95710 Summary: ICE in gfc_type_is_extensible, at fortran/resolve.c:8848 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r6, with a doubled declaration : $ cat z1.f90 module m type t integer :: a = 1 end type interface module subroutine s end end interface end submodule(m) m2 contains subroutine s ! or module subroutine s class(t), allocatable :: x class(t), allocatable :: x end end $ cat z2.f90 module m type t integer :: a = 1 end type interface module subroutine s end end interface end submodule(m) m2 contains subroutine s ! or module procedure s class(t), pointer :: x class(t), pointer :: x end end $ cat z3.f90 module m type t integer :: a = 1 end type interface module subroutine s end end interface end submodule(m) m2 contains subroutine s class(t), allocatable :: x class(t), pointer :: x end end $ gfortran-11-20200614 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbcdd2f crash_signal ../../gcc/toplev.c:328 0x5e5861 gfc_type_is_extensible(gfc_symbol*) ../../gcc/fortran/resolve.c:8848 0x5e5861 resolve_fl_var_and_proc ../../gcc/fortran/resolve.c:12658 0x6ce441 resolve_fl_variable ../../gcc/fortran/resolve.c:12774 0x6ce441 resolve_symbol ../../gcc/fortran/resolve.c:15835 0x6eb7d2 do_traverse_symtree ../../gcc/fortran/symbol.c:4162 0x6d0a84 resolve_types ../../gcc/fortran/resolve.c:17175 0x6d0b90 resolve_types ../../gcc/fortran/resolve.c:17186 0x6cc19c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17290 0x6b40f2 gfc_parse_file() ../../gcc/fortran/parse.c:6447 0x70036f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/95709] New: [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709 Bug ID: 95709 Summary: [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r8 (before 20180525), r7 rejects it : $ cat z1.f90 program p integer, parameter :: i(1) = 1 goto i(1) 1 continue end $ cat z2.f90 program p integer, parameter :: i(0) = 0 goto i(1) end $ cat z3.f90 program p integer, parameter :: i(0) = 0 goto i(0) goto i(1) goto i(-1) goto i(i(0)) end $ cat z4.f90 program p integer, parameter :: i(0) = 0 integer :: j goto i%kind goto j%kind goto j%kind, (1) end $ gfortran-11-20200614 -c z1.f90 z1.f90:3:12: 3 |goto i(1) |1 Warning: Deleted feature: Assigned GOTO statement at (1) f951: internal compiler error: Segmentation fault 0xbcdd2f crash_signal ../../gcc/toplev.c:328 0x6c9c8c gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11807 0x6cc0e7 resolve_codes ../../gcc/fortran/resolve.c:17257 0x6cc1ae gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17292 0x6b42ec resolve_all_program_units ../../gcc/fortran/parse.c:6245 0x6b42ec gfc_parse_file() ../../gcc/fortran/parse.c:6492 0x70036f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/95708] New: [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95708 Bug ID: 95708 Summary: [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Special case "team_number" gives an ICE down to r8, r7 rejects it : $ cat z0.f90 program p procedure(num_images) :: g end $ cat z1.f90 program p procedure(team_number) :: g end $ gfortran-11-20200614 -c z0.f90 z0.f90:2:29: 2 |procedure(num_images) :: g | 1 Error: Intrinsic procedure 'num_images' not allowed in PROCEDURE statement at (1) $ gfortran-11-20200614 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbcdd2f crash_signal ../../gcc/toplev.c:328 0x6cf9fb resolve_fl_procedure ../../gcc/fortran/resolve.c:13002 0x6cf9fb resolve_symbol ../../gcc/fortran/resolve.c:15855 0x6cfeca resolve_procedure_interface ../../gcc/fortran/resolve.c:210 0x6cd526 resolve_symbol ../../gcc/fortran/resolve.c:15235 0x6eb7d2 do_traverse_symtree ../../gcc/fortran/symbol.c:4162 0x6d0a84 resolve_types ../../gcc/fortran/resolve.c:17175 0x6cc19c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17290 0x6b42ec resolve_all_program_units ../../gcc/fortran/parse.c:6245 0x6b42ec gfc_parse_file() ../../gcc/fortran/parse.c:6492 0x70036f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 --- Comment #9 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:8fb4d1d58362b77da78c09740c6b5562124a369e commit r11-1395-g8fb4d1d58362b77da78c09740c6b5562124a369e Author: Aldy Hernandez Date: Tue Jun 16 13:43:57 2020 +0200 Fix pasto in the substitute_and_fold_engine merge with evrp. The original code only propagated into PHI arguments if the value was a constant. This behavior was lost in the conversion, allowing any value (SSAs for instance) to be propagated into PHIs. gcc/ChangeLog: PR tree-optimization/95649 * tree-ssa-propagate.c (propagate_into_phi_args): Do not propagate unless value is a constant. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/pr95649.C: New test. * gcc.dg/tree-ssa/pr95649.c: New test.
[Bug fortran/95707] New: ICE in finish_equivalences, at fortran/trans-common.c:1319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95707 Bug ID: 95707 Summary: ICE in finish_equivalences, at fortran/trans-common.c:1319 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Happens between name length 35 (ok) and 36 (ICE) : $ cat z1_35.f90 module m2345678901234567890123456789012345 interface module subroutine s2345678901234567890123456789012345 end end interface end submodule(m2345678901234567890123456789012345) & n2345678901234567890123456789012345 real :: a(4), u(3,2) real :: b(4), v(4,2) equivalence (a(1),u(1,1)), (b(1),v(1,1)) end $ cat z1_36.f90 module m23456789012345678901234567890123456 interface module subroutine s23456789012345678901234567890123456 end end interface end submodule(m23456789012345678901234567890123456) & n23456789012345678901234567890123456 real :: a(4), u(3,2) real :: b(4), v(4,2) equivalence (a(1),u(1,1)), (b(1),v(1,1)) end $ cat z1_63.f90 module m23456789012345678901234567890123456789012345678901234567890123 interface module subroutine s23456789012345678901234567890123456789012345678901234567890123 end end interface end submodule(m23456789012345678901234567890123456789012345678901234567890123) & n23456789012345678901234567890123456789012345678901234567890123 real :: a(4), u(3,2) real :: b(4), v(4,2) equivalence (a(1),u(1,1)), (b(1),v(1,1)) end $ gfortran-11-20200614 -c z1_35.f90 $ $ gfortran-11-20200614 -c z1_36.f90 f951: internal compiler error: in finish_equivalences, at fortran/trans-common.c:1319 0x71f615 finish_equivalences ../../gcc/fortran/trans-common.c:1319 0x71f615 gfc_trans_common(gfc_namespace*) ../../gcc/fortran/trans-common.c:1363 0x72c977 gfc_generate_module_vars(gfc_namespace*) ../../gcc/fortran/trans-decl.c:5796 0x707684 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2238 0x6b4501 translate_all_program_units ../../gcc/fortran/parse.c:6293 0x6b4501 gfc_parse_file() ../../gcc/fortran/parse.c:6545 0x70036f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c/95699] __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699 --- Comment #2 from Andrew Pinski --- Oh never mind. It is about [ if (r < 0x8000) r = 0x8000; r *= r; __builtin_constant Well it is Jump threading related.
[Bug c/95699] __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699 --- Comment #1 from Andrew Pinski --- Signed integer overflow is undefined.
[Bug testsuite/95706] New: New test case gfortran.dg/pr95690.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706 Bug ID: 95706 Summary: New test case gfortran.dg/pr95690.f90 fails Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:a97e49a89d11b302b12ec319a3316ba78adca02a, r11-1349 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr95690.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never-O -pedantic-errors -S -o pr95690.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr95690.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O -pedantic-errors -S -o pr95690.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr95690.f90:6:0: Error: initializer for floating value is not a floating constant compiler exited with status 1 FAIL: gfortran.dg/pr95690.f90 -O (test for errors, line 5) Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/ exceptions_enabled590613.cc-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -S -o exceptions_enabled590613.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/ exceptions_enabled590613.cc -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -S -o exceptions_enabled590613.s FAIL: gfortran.dg/pr95690.f90 -O (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr95690.f90:6:0: Error: initializer for floating value is not a floating constant
[Bug c++/95705] New: Internal compiler error generated when using int cast as array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95705
Bug ID: 95705
Summary: Internal compiler error generated when using int cast
as array index
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: staffordstyle at gmail dot com
Target Milestone: ---
main.ii
===
# 1 "main.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "main.cpp"
struct IntLike
{
operator int() const
{
return 0;
}
};
template
void useAsArrayIndex( const IntLike a )
{
float myArray[1];
myArray[ a ];
}
int main()
{
}
Compile command:
===
g++ -save-temps main.cpp
main.cpp: In function ‘void useAsArrayIndex(IntLike)’:
main.cpp:13:14: internal compiler error: unexpected expression ‘(int)a’ of kind
implicit_conv_expr
13 | myArray[ a ];
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/95686] undefined reference to static local variable within inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95686
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #3 from Daniel Krügler ---
(In reply to Lénárd Szolnoki from comment #2)
> I failed to mention that I compiled the example in -std=c++17. With this
> compiler option it compiles but fails to link in gcc. It compiles, links and
> runs as expected in clang.
>
> The linkage requirement for reference/pointer non-type template arguments
> were lifted in C++17.
According to https://gcc.gnu.org/bugs/ the compile options have to be provided
for every bug report. Here is a slightly simplified reproducer free of any
library dependencies:
Compiler options:
-Wall -Wextra -std=c++2a -pedantic
//---
template
struct S {
static constexpr const int* value = ptr;
};
inline
auto foo() {
static const int i = 0;
return S<&i>{};
}
void bar(const int*){}
int main() {
bar(decltype(foo())::value);
}
//---
Diagnostic output:
//
/tmp/cci6dPre.o: In function `main':
prog.cc:(.text+0x10): undefined reference to `foo()::i'
collect2: error: ld returned 1 exit status
//
[Bug c++/95705] Internal compiler error generated when using int cast as array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95705 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Marek Polacek --- It's a dup. I'll post a new patch for that today. *** This bug has been marked as a duplicate of bug 95508 ***
[Bug c++/95508] [10/11 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 Marek Polacek changed: What|Removed |Added CC||staffordstyle at gmail dot com --- Comment #1 from Marek Polacek --- *** Bug 95705 has been marked as a duplicate of this bug. ***
[Bug c++/95705] Internal compiler error generated when using int cast as array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95705 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Most likely dup of PR95508.
[Bug c++/95369] braced-init-list with designated initializers as template-argument rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95369 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- This should now work as expected.
[Bug c++/95369] braced-init-list with designated initializers as template-argument rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95369 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:04afaf4575ff239279cfa34aff17101345451965 commit r11-1392-g04afaf4575ff239279cfa34aff17101345451965 Author: Marek Polacek Date: Mon Jun 15 15:31:32 2020 -0400 c++: Don't allow designated initializers with non-aggregates [PR95369] Another part of 95369 is that we accept designated initializers with non-aggregate types. That seems to be wrong since they're part of aggregate initialization. clang/icc also reject it. There are multiple contexts where we can use designated initializers: function-like casts, member list initializers, NTTP, etc. I've adjusted add_list_candidates and implicit_conversion_error in order to to detect this case. gcc/cp/ChangeLog: PR c++/95369 * call.c (add_list_candidates): Return if a designated initializer is used with a non-aggregate. (implicit_conversion_error): Give an error for the case above. gcc/testsuite/ChangeLog: PR c++/95369 * g++.dg/cpp2a/desig11.C: Adjust dg-error. * g++.dg/cpp2a/desig16.C: New test.
[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
kuzniar95 at o2 dot pl changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #8 from kuzniar95 at o2 dot pl ---
I've discovered that turning:
[](auto) { odr_use(ch); };
into:
[](auto) { odr_use(ch); }(123);
finally triggers a longed-for error:
--
lambda.cpp: In instantiation of ‘main():: [with auto:2 = int]’:
lambda.cpp:12:34: required from here
lambda.cpp:12:24: error: ‘ch’ is not captured
12 | [](auto) { odr_use(ch); }(123);
|^~
lambda.cpp:12:6: note: the lambda has no capture-default
12 | [](auto) { odr_use(ch); }(123);
| ^
lambda.cpp:6:20: note: ‘constexpr const char ch’ declared here
6 | constexpr char ch = '=';
|
--
This is good enough for me so I'm closing this bug report.
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 --- Comment #1 from Jens Seifert --- Created attachment 48742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48742&action=edit assembly
[Bug target/95704] New: PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 Bug ID: 95704 Summary: PPC: int128 shifts should be implemented branchless Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jens.seifert at de dot ibm.com Target Milestone: --- Created attachment 48741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48741&action=edit input with branchless 128-bit shifts PowerPC processors don't like branches and branch mispredicts lead to large overhead. shift left/right unsigned __in128 can be implemented in 8 instructions which can be processed on 2 pipelines almost in parallel leading to ~5 cycle latency on Power 7 and 8. shift right algebraic __int128 can be implemented in 10 instructions. Overall comparable in latency of the branching code. In attached file you find the branch less implementations in C. And I know that this is using undefined behavior. But the resulting assembly is the interesting part. The unnecessary rldicl 8,5,0,32 at the beginning of the routines are also not necessary.
[Bug c++/95560] [8/11 Regression] ICE in comptypes, at cp/typeck.c:1498 since r7-4206-g84ff4775d41b716c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Marek Polacek --- Fixed.
[Bug c++/95701] undefined enum conversion accepted in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95701 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-06-16 --- Comment #1 from Jonathan Wakely --- We still accept it even with -fstrict-enums Interestingly, so do Clang and EDG.
[Bug c++/95560] [8/11 Regression] ICE in comptypes, at cp/typeck.c:1498 since r7-4206-g84ff4775d41b716c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560 --- Comment #11 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2661635323bd44410f1a154683eccecd2c163b46 commit r11-1391-g2661635323bd44410f1a154683eccecd2c163b46 Author: Marek Polacek Date: Tue Jun 16 13:02:23 2020 -0400 c++: Fix ICE in check_local_shadow with enum [PR95560] Another indication that perhaps this warning is emitted too early. We crash because same_type_p gets a null type: we have an enumerator without a fixed underlying type and finish_enum_value_list hasn't yet run. So check if the type is null before calling same_type_p. PR c++/95560 * name-lookup.c (check_local_shadow): Check if types are non-null before calling same_type_p. * g++.dg/warn/Wshadow-local-3.C: New test.
[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
kuzniar95 at o2 dot pl changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #7 from kuzniar95 at o2 dot pl ---
Oh, actually I'm reopening as it still incorrectly accepts code it shouldn't. I
made a wrong assumption because I incorrectly tested that using not_odr_use
function before.
So, once more:
---
void not_odr_use(char const);
void odr_use(char const&);
int main()
{
constexpr char ch = '=';
[] { not_odr_use(ch); }; // compiles, OK
[] { odr_use(ch); }; // doesn't compile, OK
[](auto) { not_odr_use(ch); }; // compiles, OK
[](auto) { odr_use(ch); }; // compiles, NOT OK (GCC should require lambda
capture)
}
---
Previous investigation on "-Wunused" is correct, i.e. if the user doesn't
instantiate a generic lambda's function call operator, it should be a warning.
[Bug c++/95703] New: Please backport 0998d2fd59e7a5eb3a3566c57625702bbdc6a05f to gcc 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95703 Bug ID: 95703 Summary: Please backport 0998d2fd59e7a5eb3a3566c57625702bbdc6a05f to gcc 9 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rafael at espindo dot la CC: jason at redhat dot com Target Milestone: --- We (seastar) recently hit a build error with gcc 9 because the fix in 0998d2fd59e7a5eb3a3566c57625702bbdc6a05f is missing. Given that P1286R2 is about c++11 and newer, could the fix be backported to gcc 9? The original commit message is: Implement P1286R2, Contra CWG1778 The C++11 requirement that an explicit exception-specification on a defaulted function match the implicit one was found to be problematic for std::atomic. This paper, adopted in February, simply removes that requirement: if an explicitly defaulted function has a different exception-specification, that now works just like a user-written function: either it isn't noexcept when it could be, or it is noexcept and will call terminate if an exception is thrown.
[Bug libstdc++/95702] New: ranges::transform missing vectorization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95702
Bug ID: 95702
Summary: ranges::transform missing vectorization opportunity
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pilarlatiesa at gmail dot com
Target Milestone: ---
GCC 10 is able to vectorize this code (https://godbolt.org/z/tsbfQw):
#include
#include
void foo(std::vector &u, std::vector const &v)
{
std::transform(std::begin(u), std::end(u),
std::begin(v),
std::begin(u),
std::plus());
}
However, it fails to vectorize the ranges equivalent
(https://godbolt.org/z/D49hJa):
#include
#include
void foo(std::vector &u, std::vector const &v)
{
std::ranges::transform(u, v, std::begin(u), std::plus());
}
The option -fopt-info-vec-missed reveals why:
bits/ranges_algo.h:986:29: missed: not vectorized: number of iterations cannot
be computed.
Would an optimization like the following one make sense?
template _Sent1,
input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
weakly_incrementable _Out, copy_constructible _Fp,
typename _Proj1 = identity, typename _Proj2 = identity>
requires indirectly_writable<_Out,
indirect_result_t<_Fp&,
projected<_Iter1, _Proj1>,
projected<_Iter2, _Proj2>>>
constexpr binary_transform_result<_Iter1, _Iter2, _Out>
operator()(_Iter1 __first1, _Sent1 __last1,
_Iter2 __first2, _Sent2 __last2,
_Out __result, _Fp __binary_op,
_Proj1 __proj1 = {}, _Proj2 __proj2 = {}) const
{
+ if constexpr (random_access_iterator<_Iter1>
+ && random_access_iterator<_Iter2>)
+ {
+ auto __d1 = ranges::distance(__first1, __last1);
+ auto __d2 = ranges::distance(__first2, __last2);
+ auto __n = std::min(__d1, __d2);
+ for (decltype(__n) __i = 0; __i < __n;
+(void)++__i, (void)++__first1, (void)++__first2,
++__result)
+ }
+ else
for (; __first1 != __last1 && __first2 != __last2;
++__first1, (void)++__first2, ++__result)
*__result = std::__invoke(__binary_op,
std::__invoke(__proj1,
*__first1),
std::__invoke(__proj2,
*__first2));
return {std::move(__first1), std::move(__first2),
std::move(__result)};
}
[Bug tree-optimization/95697] Failure to optimize float comparison of converted integer to integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697 --- Comment #2 from joseph at codesourcery dot com --- See bug 60540, of which this is probably a duplicate, noting the issue with losing "inexact" exceptions (and "overflow" for some types) and the reference to bug 57371 for a more detailed discussion of the conditions under which such optimizations are valid.
[Bug c++/95701] New: undefined enum conversion accepted in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95701
Bug ID: 95701
Summary: undefined enum conversion accepted in constant
expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leni536 at gmail dot com
Target Milestone: ---
gcc accepts the following code:
enum E {
one = 1
};
constexpr E foo() {
return static_cast(0x);
}
void bar() {
constexpr auto e = foo();
}
Relevant parts of the standard:
https://timsong-cpp.github.io/cppwp/n4659/expr.const#2.6
https://timsong-cpp.github.io/cppwp/n4659/expr.static.cast#10
> The value is unchanged if the original value is within the range of the
> enumeration values ([dcl.enum]). Otherwise, the behavior is undefined.
https://timsong-cpp.github.io/cppwp/n4659/dcl.enum#8
Following the wording here the "range of the enumeration values" is [0, 1].
[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842 --- Comment #6 from kuzniar95 at o2 dot pl --- P.S. odr_use function signature should be: void odr_use(const char&);
[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
kuzniar95 at o2 dot pl changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from kuzniar95 at o2 dot pl ---
Actually everything is done well, my bad, sorry.
This code explains what's going on:
---
void not_odr_use(char);
void odr_use(char&);
int main()
{
constexpr char ch1 = '=';
[] { not_odr_use(ch1); }; // compiles
[] { odr_use(ch1); }; // doesn't compile and it shouldn't
constexpr char ch2 = '=';
[](auto) { not_odr_use(ch2); }; // this line doesn't instantiate the
template (generic lambda is like a hidden template function) so "ch2" never
gets to be used
}
---
I'm happy to close this and confirm that it isn't a compiler bug.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #6 from Jonathan Wakely --- To be really safe during stage 1, GCC should not use NULL as a pointer sentinel in C++ code anyway. The bootstrap compiler could define it to 0 or 0u, neither of which is guaranteed to be OK to pass as a varargs sentinel where a null pointer is expected. Any of (void*)0 or (void*)NULL or nullptr would be safe.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #5 from Ilya Leoshkevich --- I'm sorry, I should not have written (uintptr_t)0 - I just used it as a synonym for a "pointer-sized int". Would allowing 0L as a sentinel value be a reasonable thing?
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #4 from Ilya Leoshkevich --- Created attachment 48740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48740&action=edit preprocessed output In the preprocessed output I see that gcc's stddef.h is used, but most likely `#define NULL 0L` comes from some other musl header, since musl defines it in like 8 places.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #3 from Jonathan Wakely --- (In reply to Ilya Leoshkevich from comment #0) > musl has the following commit: > https://git.musl-libc.org/cgit/musl/commit/ > ?id=c8a9c22173f485c8c053709e1dfa0a617cb6be1a, which suggests that C++ (as > opposed to plain C) should allow plain (uintptr_t)0 as a sentinel value. I don't understand. musl uses a null pointer constant of type long (i.e. 0L) so where does the suggestion to allow (uintptr_t)0 come from? If C provided a UINTPTR_C macro to produce an integer literal of type uintptr_t then UINTPTR_C(0) would be a valid sentinel. I assume that doesn't exist because C doesn't need such a type (because defining NULL to (void*)0 avoids this problem).
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #2 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #1) > I don't think it is a good idea to allow (uintptr_t) 0 as valid sentinel. Definitely not. (uintptr_t)0 is not a null pointer constant, and is not a valid definition of NULL for C++.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #39 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #38) > Created attachment 48738 [details] > Patch candidate v2 I have added this patch to my private gcc 8 with some change, works fine with the small testing case, and fixed the bug I reported in comment #36. > > There's a properly tested patch that supports all operations. > Please apply also pending patch: > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548206.html do I need to apply this as well in order to get the data from the real application? (note I need to apply the patch to gcc 8, this patch is not easy to be applied to gcc 8).
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why isn't gcc's own stddef.h used rather than the musl one? I don't think it is a good idea to allow (uintptr_t) 0 as valid sentinel.
[Bug c++/95700] New: read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
Bug ID: 95700
Summary: read-md.c: "missing sentinel in function call" when
building gcc with musl
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
I'm trying to bootstrap gcc on gcc301 with --disable-multilib
--build=x86_64-alpine-linux-musl. The following error occurs:
/home/iii/gcc/regtest-f8a59086423e/build/./prev-gcc/xg++
-B/home/iii/gcc/regtest-f8a59086423e/build/./prev-gcc/
-B/home/iii/gcc/regtest-f8a59086423e/install/x86_64-alpine-linux-musl/bin/
-nostdinc++
-B/home/iii/gcc/regtest-f8a59086423e/build/prev-x86_64-alpine-linux-musl/libstdc++-v3/src/.libs
-B/home/iii/gcc/regtest-f8a59086423e/build/prev-x86_64-alpine-linux-musl/libstdc++-v3/libsupc++/.libs
-I/home/iii/gcc/regtest-f8a59086423e/build/prev-x86_64-alpine-linux-musl/libstdc++-v3/include/x86_64-alpine-linux-musl
-I/home/iii/gcc/regtest-f8a59086423e/build/prev-x86_64-alpine-linux-musl/libstdc++-v3/include
-I/home/iii/gcc/regtest-f8a59086423e/libstdc++-v3/libsupc++
-L/home/iii/gcc/regtest-f8a59086423e/build/prev-x86_64-alpine-linux-musl/libstdc++-v3/src/.libs
-L/home/iii/gcc/regtest-f8a59086423e/build/prev-x86_64-alpine-linux-musl/libstdc++-v3/libsupc++/.libs
-c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE
-fno-PIE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include
-I../../gcc/../libcpp/include \
-o build/read-md.o ../../gcc/read-md.c
../../gcc/read-md.c: In member function ‘const char*
md_reader::join_c_conditions(const char*, const char*)’:
../../gcc/read-md.c:158:58: error: missing sentinel in function call
[-Werror=format=]
158 | result = concat ("(", cond1, ") && (", cond2, ")", NULL);
| ^
../../gcc/read-md.c: In member function ‘void
md_reader::handle_enum(file_location, bool)’:
../../gcc/read-md.c:947:58: error: missing sentinel in function call
[-Werror=format=]
947 |value_name = concat (def->name, "_", name.string, NULL);
| ^
../../gcc/read-md.c: In member function ‘void
md_reader::handle_include(file_location)’:
../../gcc/read-md.c:1072:57: error: missing sentinel in function call
[-Werror=format=]
1072 |pathname = concat (stackp->fname, sep, filename, NULL);
| ^
../../gcc/read-md.c:1085:47: error: missing sentinel in function call
[-Werror=format=]
1085 | pathname = concat (m_base_dir, filename, NULL);
| ^
cc1plus: all warnings being treated as errors
musl has the following commit:
https://git.musl-libc.org/cgit/musl/commit/?id=c8a9c22173f485c8c053709e1dfa0a617cb6be1a,
which suggests that C++ (as opposed to plain C) should allow plain (uintptr_t)0
as a sentinel value.
gcc wants either a pointer or __null though:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-common.c;h=b1379faa412e3646a443969c0067f5c4fb23e107;hb=929fd91ba975eebf9e57f7f092041271dcaf0c34#l5385
Would it be possible to allow (uintptr_t)0 as a valid sentinel value for C++?
Or is it musl that is wrong here?
[Bug c/95699] New: __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699
Bug ID: 95699
Summary: __builtin_constant_p inconsistencies
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code on x86_64 (written for a 64-bit long), compiled
with -O2.
With gcc-9 (Debian 9.3.0-13) 9.3.0, I get:
0
1
1
With gcc-10 (Debian 10.1.0-3) 10.1.0, I get:
0
1
0
I'm not sure about the exact __builtin_constant_p specification, i.e. whether
it may be duplicated into two branches so that the argument can become a
constant for GCC (I think it should as this may allow the selection of code
optimized for constants), and how this can be influenced by "volatile".
But the first two cases are very similar, so that I would expect the same
value, but I get 0 / 1 with both GCC 9 and GCC 10. Concerning the third case,
the constantness has been lost in GCC 10, which is unexpected if a result 1 is
allowed.
Moreover, if I remove the second condition ("&& ...") in the printf, I always
get 0 (i.e. false), which is counter-intuitive: adding a "&& ..." condition
should never change a false condition to true (the results 1 I obtain above).
int printf (const char *__restrict __format, ...);
#undef C
#define C 0x7fffUL
static void tst1a (void)
{
volatile unsigned long r0 = 0;
unsigned long r;
r = r0;
if (r < C)
r = C;
printf ("%d\n", __builtin_constant_p (r) && r == C);
}
#undef C
#define C 0x8000UL
static void tst1b (void)
{
volatile unsigned long r0 = 0;
unsigned long r;
r = r0;
if (r < C)
r = C;
printf ("%d\n", __builtin_constant_p (r) && r == C);
}
static void tst2 (void)
{
volatile unsigned long r0 = 0;
unsigned long r;
r = r0;
if (r < 0x8000)
r = 0x8000;
r *= r;
printf ("%d\n", __builtin_constant_p (r) && r < 1);
}
int main (void)
{
tst1a ();
tst1b ();
tst2 ();
return 0;
}
[Bug tree-optimization/95697] Failure to optimize float comparison of converted integer to integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697 --- Comment #1 from Gabriel Ravier --- *** Bug 95698 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/95698] Failure to optimize float comparison of converted integer to integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95698 Gabriel Ravier changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Gabriel Ravier --- No idea how this ended up being created twice but this is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697 *** This bug has been marked as a duplicate of bug 95697 ***
[Bug tree-optimization/95698] New: Failure to optimize float comparison of converted integer to integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95698
Bug ID: 95698
Summary: Failure to optimize float comparison of converted
integer to integer comparison
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(int n)
{
return (float)n > 0.0;
}
This can be optimized to `return n > 0;`. This transformation is done by LLVM,
but not by GCC.
[Bug tree-optimization/95697] New: Failure to optimize float comparison of converted integer to integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697
Bug ID: 95697
Summary: Failure to optimize float comparison of converted
integer to integer comparison
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(int n)
{
return (float)n > 0.0;
}
This can be optimized to `return n > 0;`. This transformation is done by LLVM,
but not by GCC.
[Bug tree-optimization/92029] [10/11 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92029 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #9) > This is fixed by Tobias' PR94848, PR95551 commit > 1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8 "openmp: ensure variables in > offload table are streamed out (PRs 94848 + 95551)". Tobias, please verify > this is expected, etc. (I think I have written a comment at least twice but somehow it was never saved.) FIXED. Comment 2 (plus comment 4) exactly describes what the patch for PR94848 and PR95551 does.
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > This is probably another dup of PR 41437 Apparently not.
[Bug c++/94644] Wrong is_nothrow_move_constructible result if used in a template first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jonathan Wakely --- PR 41437 was fixed, and as expected this seems to be fixed now too. You get an error with or without -Dfoo (which seems correct to me). *** This bug has been marked as a duplicate of bug 41437 ***
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 --- Comment #14 from Jonathan Wakely --- *** Bug 94644 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 --- Comment #8 from Jeffrey A. Law --- I still don't understand why propagating one SSA_NAME for another is causing headaches later though. I don't see anything fundamentally wrong with your patch and it restores previous behavior since singleton_p would only be true for a constant, so consider it pre-approved.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #41 from Andrew Downing --- > Thus for types without a non-trivial ctor/dtor you do not need to use > placement new. So take your example and remove the placement new. > Does that change its semantics? These are C++17 rules. 4.5/1) An object is created by a definition, by a new-expression, when implicitly changing the active member of a union, or when a temporary object is created. 6.8/1) The lifetime of an object of type T begins when: storage with the proper alignment and size for type T is obtained, and if the object has non-vacuous initialization, its initialization is complete. double d; My interpretation of the above rules would be that only a double object is created in the storage for d because T in 6.8/1 is set to double by the definition of d. According to these rules the only way to change the dynamic type of the object in d's storage would be with placement new (pre C++20). memcpy only overwrites the object representation. It doesn't affect it's type or lifetime. If you remove the placement new from my example, the program has undefined behavior because it later accesses the double object with a uint64_t pointer. With placement new in place, it accesses a uint64_t object in d's storage with a uint64_t pointer. In C++20 the placement new wouldn't be required because in addition to the things above that create objects, you also have operations that implicitly create objects of which memcpy is one. The rules are different than C's though. The only objects that are or are not created are ones that would give the program defined behavior. So in f1 where the uint64_t* pointing to d is accessed, the compiler would have to make the second memcpy create a uint64_t object in d's storage before copying the bytes to give the subsequent access through a uint64_t* defined behavior. If you used placement new anyway, then the second memcpy wouldn't have to create an object because the program would already have defined behavior.
[Bug target/94735] MVE vector load/store pair getting removed with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94735 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:aac5ae144363dbd857654511fbf335e53c8f7cf5 commit r10-8312-gaac5ae144363dbd857654511fbf335e53c8f7cf5 Author: Srinath Parvathaneni Date: Tue Jun 16 12:53:23 2020 +0100 arm: Correct the grouping of operands in MVE vector scatter store intrinsics (PR94735). The operands in RTL patterns of MVE vector scatter store intrinsics are wrongly grouped, because of which few vector loads and stores instructions are wrongly getting optimized out with -O2. A new predicate "mve_scatter_memory" is defined in this patch, this predicate returns TRUE on matching: (mem(reg)) for MVE scatter store intrinsics. This patch fixes the issue by adding define_expand pattern with "mve_scatter_memory" predicate and calls the corresponding define_insn by passing register_operand as first argument. This register_operand is extracted from the operand with "mve_scatter_memory" predicate in define_expand pattern. Backported from mainline 2020-06-04 Srinath Parvathaneni gcc/ PR target/94735 * config/arm/predicates.md (mve_scatter_memory): Define to match (mem (reg)) for scatter store memory. * config/arm/mve.md (mve_vstrbq_scatter_offset_): Modify define_insn to define_expand. (mve_vstrbq_scatter_offset_p_): Likewise. (mve_vstrhq_scatter_offset_): Likewise. (mve_vstrhq_scatter_shifted_offset_p_): Likewise. (mve_vstrhq_scatter_shifted_offset_): Likewise. (mve_vstrdq_scatter_offset_p_v2di): Likewise. (mve_vstrdq_scatter_offset_v2di): Likewise. (mve_vstrdq_scatter_shifted_offset_p_v2di): Likewise. (mve_vstrdq_scatter_shifted_offset_v2di): Likewise. (mve_vstrhq_scatter_offset_fv8hf): Likewise. (mve_vstrhq_scatter_offset_p_fv8hf): Likewise. (mve_vstrhq_scatter_shifted_offset_fv8hf): Likewise. (mve_vstrhq_scatter_shifted_offset_p_fv8hf): Likewise. (mve_vstrwq_scatter_offset_fv4sf): Likewise. (mve_vstrwq_scatter_offset_p_fv4sf): Likewise. (mve_vstrwq_scatter_offset_p_v4si): Likewise. (mve_vstrwq_scatter_offset_v4si): Likewise. (mve_vstrwq_scatter_shifted_offset_fv4sf): Likewise. (mve_vstrwq_scatter_shifted_offset_p_fv4sf): Likewise. (mve_vstrwq_scatter_shifted_offset_p_v4si): Likewise. (mve_vstrwq_scatter_shifted_offset_v4si): Likewise. (mve_vstrbq_scatter_offset__insn): Define insn for scatter stores. (mve_vstrbq_scatter_offset_p__insn): Likewise. (mve_vstrhq_scatter_offset__insn): Likewise. (mve_vstrhq_scatter_shifted_offset_p__insn): Likewise. (mve_vstrhq_scatter_shifted_offset__insn): Likewise. (mve_vstrdq_scatter_offset_p_v2di_insn): Likewise. (mve_vstrdq_scatter_offset_v2di_insn): Likewise. (mve_vstrdq_scatter_shifted_offset_p_v2di_insn): Likewise. (mve_vstrdq_scatter_shifted_offset_v2di_insn): Likewise. (mve_vstrhq_scatter_offset_fv8hf_insn): Likewise. (mve_vstrhq_scatter_offset_p_fv8hf_insn): Likewise. (mve_vstrhq_scatter_shifted_offset_fv8hf_insn): Likewise. (mve_vstrhq_scatter_shifted_offset_p_fv8hf_insn): Likewise. (mve_vstrwq_scatter_offset_fv4sf_insn): Likewise. (mve_vstrwq_scatter_offset_p_fv4sf_insn): Likewise. (mve_vstrwq_scatter_offset_p_v4si_insn): Likewise. (mve_vstrwq_scatter_offset_v4si_insn): Likewise. (mve_vstrwq_scatter_shifted_offset_fv4sf_insn): Likewise. (mve_vstrwq_scatter_shifted_offset_p_fv4sf_insn): Likewise. (mve_vstrwq_scatter_shifted_offset_p_v4si_insn): Likewise. (mve_vstrwq_scatter_shifted_offset_v4si_insn): Likewise. gcc/testsuite/ PR target/94735 * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_base.c: New test. * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_base_p.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_offset.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_offset_p.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_shifted_offset.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_shifted_offset_p.c: Likewise.
[Bug target/94959] Wrong code gen for MVE intrinsics vldrbq_s32 which fails with assembler `Error: lo register required`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94959 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:32c348ce3efd1d693df43045338c8c3e33798edd commit r10-8310-g32c348ce3efd1d693df43045338c8c3e33798edd Author: Srinath Parvathaneni Date: Tue Jun 16 13:26:41 2020 +0100 arm: Fix the wrong code-gen generated by MVE vector load/store intrinsics (PR94959). Few MVE intrinsics like vldrbq_s32, vldrhq_s32 etc., the assembler instructions generated by current compiler are wrong. eg: vldrbq_s32 generates an assembly instructions `vldrb.s32 q0,[ip]`. But as per Arm-arm second argument in above instructions must also be a low register (<= r7). This patch fixes this issue by creating a new predicate "mve_memory_operand" and constraint "Ux" which allows low registers as arguments to the generated instructions depending on the mode of the argument. A new constraint "Ul" is created to handle loading to PC-relative addressing modes for vector store/load intrinsiscs. All the corresponding MVE intrinsic generating wrong code-gen as vldrbq_s32 are modified in this patch. Backported from mainline 2020-05-20 Srinath Parvathaneni gcc/ PR target/94959 * config/arm/arm-protos.h (arm_mode_base_reg_class): Function declaration. (mve_vector_mem_operand): Likewise. * config/arm/arm.c (thumb2_legitimate_address_p): For MVE target check the load from memory to a core register is legitimate for give mode. (mve_vector_mem_operand): Define function. (arm_print_operand): Modify comment. (arm_mode_base_reg_class): Define. * config/arm/arm.h (MODE_BASE_REG_CLASS): Modify to add check for TARGET_HAVE_MVE and expand to arm_mode_base_reg_class on TRUE. * config/arm/constraints.md (Ux): Likewise. (Ul): Likewise. * config/arm/mve.md (mve_mov): Replace constraint Us with Ux and also add support for missing Vector Store Register and Vector Load Register. Add a new alternative to support load from memory to PC (or label) in vector store/load. (mve_vstrbq_): Modify constraint Us to Ux. (mve_vldrbq_): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vldrbq_z_): Modify constraint Us to Ux. (mve_vldrhq_fv8hf): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vldrhq_): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vldrhq_z_fv8hf): Likewise. (mve_vldrhq_z_): Likewise. (mve_vldrwq_fv4sf): Likewise. (mve_vldrwq_v4si): Likewise. (mve_vldrwq_z_fv4sf): Likewise. (mve_vldrwq_z_v4si): Likewise. (mve_vld1q_f): Modify constriant Us to Ux. (mve_vld1q_): Likewise. (mve_vstrhq_fv8hf): Modify constriant Us to Ux, predicate to mve_memory_operand. (mve_vstrhq_p_fv8hf): Modify constriant Us to Ux, predicate to mve_memory_operand and also modify the MVE instructions to emit. (mve_vstrhq_p_): Likewise. (mve_vstrhq_): Modify constriant Us to Ux, predicate to mve_memory_operand. (mve_vstrwq_fv4sf): Modify constriant Us to Ux. (mve_vstrwq_p_fv4sf): Modify constriant Us to Ux and also modify the MVE instructions to emit. (mve_vstrwq_p_v4si): Likewise. (mve_vstrwq_v4si): Likewise.Modify constriant Us to Ux. * config/arm/predicates.md (mve_memory_operand): Define. gcc/testsuite/ PR target/94959 * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Modify. * gcc.target/arm/mve/intrinsics/mve_vldr.c: New test. * gcc.target/arm/mve/intrinsics/mve_vldr_z.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstr.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_vstr_p.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_f16.c: Modify. * gcc.target/arm/mve/intrinsics/vld1q_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_s16.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_s8.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_u16.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_u32.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_u8.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_z_f16.c: Likewise. * gcc.target/arm/mve/intrinsics/vld1q_z_f32.c
[Bug rtl-optimization/95696] regrename creates overlapping register allocations for vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696 zhongyunde at tom dot com changed: What|Removed |Added CC||zhongyunde at tom dot com --- Comment #1 from zhongyunde at tom dot com --- Created attachment 48739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48739&action=edit Step 7: Close chains for registers that were never really used delayed at the end of vliw I make a patch, please help to review, tks.
[Bug middle-end/95622] [11 Regression] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta{-2,-4,}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:7d249d84e4c1be7c6f857c3a9d7791623a0e9d00 commit r10-8309-g7d249d84e4c1be7c6f857c3a9d7791623a0e9d00 Author: Tobias Burnus Date: Tue Jun 16 15:14:13 2020 +0200 testsuite: Add offloading_enabled check and use it for xfail (PR95622) gcc/testsuite/ChangeLog: PR middle-end/95622 * lib/target-supports.exp (check_effective_target_offloading_enabled): New. * c-c++-common/goacc/kernels-alias-ipa-pta-2.c: Use it for xfail. * c-c++-common/goacc/kernels-alias-ipa-pta-4.c: Likewise. * c-c++-common/goacc/kernels-alias-ipa-pta.c: Likewise. Reviewed-by: Thomas Schwinge (cherry picked from commit e70fbee1a3dd9fdeb661366dbf3096d76c4e2d6e)
[Bug middle-end/95622] [11 Regression] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta{-2,-4,}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:e70fbee1a3dd9fdeb661366dbf3096d76c4e2d6e commit r11-1384-ge70fbee1a3dd9fdeb661366dbf3096d76c4e2d6e Author: Tobias Burnus Date: Tue Jun 16 15:14:13 2020 +0200 testsuite: Add offloading_enabled check and use it for xfail (PR95622) gcc/testsuite/ChangeLog: PR middle-end/95622 * lib/target-supports.exp (check_effective_target_offloading_enabled): New. * c-c++-common/goacc/kernels-alias-ipa-pta-2.c: Use it for xfail. * c-c++-common/goacc/kernels-alias-ipa-pta-4.c: Likewise. * c-c++-common/goacc/kernels-alias-ipa-pta.c: Likewise. Reviewed-by: Thomas Schwinge
[Bug target/95488] Suboptimal multiplication codegen for v16qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95488 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2020-06-16 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #8 from H.J. Lu --- -march=skylake-avx512 gave: [hjl@gnu-cfl-2 gcc]$ /export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx512bw-pr95488-1.c -march=skylake-avx512 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -ffat-lto-objects -fno-ident -S -o avx512bw-pr95488-1.s [hjl@gnu-cfl-2 gcc]$ cat avx512bw-pr95488-1.s .file "avx512bw-pr95488-1.c" .text .p2align 4 .globl mul_512 .type mul_512, @function mul_512: .LFB0: .cfi_startproc vpunpcklbw %ymm0, %ymm0, %ymm3 vpunpcklbw %ymm1, %ymm1, %ymm2 vpunpckhbw %ymm0, %ymm0, %ymm0 vpunpckhbw %ymm1, %ymm1, %ymm1 vpmullw %ymm3, %ymm2, %ymm2 vpmullw %ymm0, %ymm1, %ymm1 vpshufb .LC0(%rip), %ymm2, %ymm0 vpshufb .LC1(%rip), %ymm1, %ymm1 vpor%ymm1, %ymm0, %ymm0 ret .cfi_endproc .LFE0: .size mul_512, .-mul_512 .p2align 4 .globl umul_512 .type umul_512, @function umul_512: .LFB1: .cfi_startproc vpunpcklbw %ymm0, %ymm0, %ymm3 vpunpcklbw %ymm1, %ymm1, %ymm2 vpunpckhbw %ymm0, %ymm0, %ymm0 vpunpckhbw %ymm1, %ymm1, %ymm1 vpmullw %ymm3, %ymm2, %ymm2 vpmullw %ymm0, %ymm1, %ymm1 vpshufb .LC0(%rip), %ymm2, %ymm0 vpshufb .LC1(%rip), %ymm1, %ymm1 vpor%ymm1, %ymm0, %ymm0 ret .cfi_endproc .LFE1: .size umul_512, .-umul_512
[Bug libstdc++/94003] is_constructible seems to have sideeffects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94003 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |11.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Patrick Palka --- Fixed for GCC 11.
