[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #8 from Iain Sandoe --- (In reply to David Malcolm from comment #7) > (In reply to r...@cebitec.uni-bielefeld.de from comment #6) > [...] > > On Solaris (both sparc and x86), all analyzer testsuite failures are > > gone. > > Thanks. > > I'll go ahead and mark this as resolved. Please reopen if there are any > other failures (apart from the pattern-test-2.c issue, which is PR > analyzer/93291). Hi David, Things are much improved on Darwin, but certainly not (yet) all fixed (see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01146.html and the next few entries). * analyzer/abort.c fails everywhere on Darwin with: /src-local/gcc-master/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: UNKNOWN PASS: gcc.dg/analyzer/abort.c (test for warnings, line 14) PASS: gcc.dg/analyzer/abort.c (test for warnings, line 31) PASS: gcc.dg/analyzer/abort.c (test for warnings, line 47) PASS: gcc.dg/analyzer/abort.c (test for warnings, line 60) FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71) FAIL: gcc.dg/analyzer/abort.c (test for excess errors) Excess errors: /src-local/gcc-master/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: UNKNOWN * analyzer/dot-output.c: fails on 32bit HOSTs (x86 and PPC) with: Warning: dot-output.c.state-purge.dot:11: string ran past end of line Error: dot-output.c.state-purge.dot:12: syntax error near line 12 context: >>> ' <<< _5' not needed here Warning: dot-output.c.state-purge.dot:34: string ran past end of line Warning: dot-output.c.state-purge.dot:45: string ran past end of line * analyzer/malloc-1.c: fails on x86_64 HOSTs with: PASS: gcc.dg/analyzer/malloc-1.c (test for warnings, line 393) FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 417) FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 418) FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 425) FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 429) XFAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 445) PASS: gcc.dg/analyzer/malloc-1.c (test for warnings, line 453) powerpc-darwin9 (32b host) has a couple of additional fails, including the pattern-test-2.c case. Do you want me to re-open this or open one or more new ones?
[Bug c++/93406] No argument checking for wchar_t variants of print-like functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93406 jerome.h...@planete-sciences.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from jerome.h...@planete-sciences.org --- (In reply to Joseph S. Myers from comment #1) > Duplicate. > > *** This bug has been marked as a duplicate of bug 38308 *** Hi,(In reply to Joseph S. Myers from comment #1) > Duplicate. > > *** This bug has been marked as a duplicate of bug 38308 *** Hi, Sorry for the duplicate bug report entry. Sorry again, I did not fully understand the comment in the first bug report (although I DID understand that it was posted over 10 years ago!), is there a fundamental reason making this difficult? I must admit that I was just bitten by this (because the size of time_t changed when we updated our development environment). Cheers, Jérôme.
[Bug c++/91006] [10 Regression] Several test suite fails on *darwin* after r272618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91006 Iain Sandoe changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Sandoe --- (In reply to Jason Merrill from comment #8) > I can't see any difference on flifetime-dse2.C from reverting that change, > and https://gcc.gnu.org/ml/gcc-testresults/2019-12/msg01137.html doesn't > show these tests failing, so this seems to be fixed now. agreed, closing as fixed (although not sure what fixed it...)
[Bug target/92469] ICE: output_operand: invalid use of register 'frame' in 7/8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469 --- Comment #6 from Uroš Bizjak --- -"What seems to be the problem?" -"It hurts when I do this." -"Then don't do that."
[Bug middle-end/86912] Function pointer imposes an optimization barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86912 Kim Nilsson changed: What|Removed |Added CC||kim.nilsson at effnet dot com --- Comment #2 from Kim Nilsson --- Some of our projects make heavy use of std::variant and we are beginning to notice a discrepancy in performance between GCC and Clang, specifically due to the lack of this optimization. Is anyone going to take a look at this, or should we take the time to upload a patch somewhere? Thank you
[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #7 from Tamar Christina --- (In reply to Martin Liška from comment #2) > So the issue started with r8-349-gcc5b8f3d568e95ce74e03d8d87ada71117a6c106 > and disappeared in r10-2445-g5fbc8ab48a57a75e0ce064befc30dee3dc63327a. Hi Martin, How do I build gcc around those commits? I have tried building x86_64 around 5b8f3d568e95ce74e03d8d87ada71117a6c106 and it keeps failing for the commits around there with a libgcc compile error. In file included from /data/tamchr01/write-access/gcc-git/libgcc/unwind-dw2.c:403:0: ./md-unwind-support.h: In function 'x86_64_fallback_frame_state': ./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type 'struct ucontext' sc = (struct sigcontext *) (void *) &uc_->uc_mcontext; and disabling libgcc doesn't get me very far because of the dependencies of things on it.
[Bug debug/92763] [8/9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22659, or in force_type_die, at dwarf2out.c:26224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92763 --- Comment #7 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:ad8e2415d6e2dc7c6f1206e78d48f999ff6b0bc4 commit r10-6199-gad8e2415d6e2dc7c6f1206e78d48f999ff6b0bc4 Author: Christophe Lyon Date: Fri Jan 24 09:07:58 2020 + debug/92763 Fix testcase to require fopenmp The testcase fails to link on targets without -pthread which is implied by -fopenmp. Use dg-require-effective-target fopenmp to avoid this problem. 2020-01-24 Christophe Lyon PR debug/92763 * g++.dg/debug/pr92763.C: Require fopenmp.
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #3 from Rainer Orth --- The new test FAILs on Solaris/SPARC, both 32 and 64-bit: +FAIL: gcc.dg/analyzer/pr93375.c (test for warnings, line 14) +FAIL: gcc.dg/analyzer/pr93375.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/pr93375.c:14:3: warning: use of NULL 'rl' where non-null expected [CWE-690] [-Wanalyzer-null-argument]
[Bug middle-end/86912] Function pointer imposes an optimization barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86912
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-24
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Martin Sebor ---
I'll confirm this but I'm not sure if the problem is substantively different
than something as simple as the following C program where GCC doesn't fold the
array reference to zero. Even declaring the array at file scope doesn't help.
(I'm pretty sure there is a report of this optimization opportunity somewhere
in Bugzilla.)
$ cat u.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.c
int f (int i)
{
const int a[] = { 0, 0, 0 };
return a[i]; // should be folded to return 0;
}
;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=1, symbol_order=0)
f (int i)
{
const int a[3];
int _6;
[local count: 1073741824]:
MEM [(int *)&a] = 0;
a[2] = 0;
_6 = a[i_5(D)];
a ={v} {CLOBBER};
return _6;
}
[Bug tree-optimization/78305] [6 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78305 --- Comment #10 from Martin Sebor --- *** Bug 71608 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/71608] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71608 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||10.0, 8.3.0, 9.2.0 Resolution|--- |DUPLICATE Known to fail||7.1.0 --- Comment #6 from Martin Sebor --- Works on trunk. Resolving as a dupe of pr78305 based comment 5. *** This bug has been marked as a duplicate of bug 78305 ***
[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91975 --- Comment #7 from Martin Sebor --- On GCC 10.0 trunk, f0 is not unrolled anymore (as it is with GCC 9.2). g0 is still not unrolled. All other functions are still unrolled as before in GCC 10.
[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924 --- Comment #11 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:e3fe0070c189e214d51cfc314591b6ffa526fb2f commit r10-6200-ge3fe0070c189e214d51cfc314591b6ffa526fb2f Author: Jan Hubicka Date: Fri Jan 24 12:12:17 2020 +0100 libgcov: Fix merging of topn [PR92924] PR tree-optimization/92924 * libgcov-merge.c (merge_topn_values_set): Fix merging.
[Bug tree-optimization/93411] New: variable reference to constant array with same elements not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93411
Bug ID: 93411
Summary: variable reference to constant array with same
elements not folded
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This was prompted by pr86912 (not sure if the problem there would be solved by
solving this one). The following test case shows that while constant
references to constant arrays are folded (both in-bounds and out-of-bounds),
non-constant references are not even though they could be.
$ cat u.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.c
const int a[] = { 0, 0, 0 };
int idx_cst_in_bounds (void)
{
return a[1]; // valid, folded to 0 (good)
}
int idx_cst_out_of_bounds (void)
{
return a[-123]; // invalid, folded to 0 without a warning (see pr86691)
}
int idx_rng_in_bounds (int i)
{
if (i < 0 || 3 < i) i = 0;
return a[i]; // valid, not folded but could/should be
}
int idx_unknown (int i)
{
return a[i]; // valid, not folded but could/should be
}
int idx_rng_out_of_bounds (int i)
{
if (i >= 0) i = -1;
return a[i]; // invalid, not folded with warning; should it be?
}
;; Function idx_cst_in_bounds (idx_cst_in_bounds, funcdef_no=0, decl_uid=1931,
cgraph_uid=1, symbol_order=1)
idx_cst_in_bounds ()
{
[local count: 1073741824]:
return 0;
}
;; Function idx_cst_out_of_bounds (idx_cst_out_of_bounds, funcdef_no=6,
decl_uid=1934, cgraph_uid=2, symbol_order=2)
idx_cst_out_of_bounds ()
{
[local count: 1073741824]:
return 0;
}
;; Function idx_rng_in_bounds (idx_rng_in_bounds, funcdef_no=2, decl_uid=1937,
cgraph_uid=3, symbol_order=3)
Removing basic block 5
idx_rng_in_bounds (int i)
{
unsigned int i.0_1;
int pretmp_6;
int prephitmp_7;
[local count: 1073741824]:
i.0_1 = (unsigned int) i_3(D);
if (i.0_1 > 3)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
pretmp_6 = a[i_3(D)];
[local count: 1073741824]:
# prephitmp_7 = PHI
return prephitmp_7;
}
;; Function idx_unknown (idx_unknown, funcdef_no=3, decl_uid=1940,
cgraph_uid=4, symbol_order=4)
idx_unknown (int i)
{
int _3;
[local count: 1073741824]:
_3 = a[i_2(D)];
return _3;
}
u.c: In function ‘idx_rng_out_of_bounds’:
u.c:27:11: warning: array subscript -1 is below array bounds of ‘const int[3]’
[-Warray-bounds]
27 | return a[i]; // not folded with warning; should it be?
| ~^~~
u.c:1:11: note: while referencing ‘a’
1 | const int a[] = { 0, 0, 0 };
| ^
;; Function idx_rng_out_of_bounds (idx_rng_out_of_bounds, funcdef_no=4,
decl_uid=1943, cgraph_uid=5, symbol_order=5)
idx_rng_out_of_bounds (int i)
{
int _4;
[local count: 1073741824]:
i_2 = MIN_EXPR ;
_4 = a[i_2];
return _4;
}
[Bug target/93412] New: [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_add_overflow() at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93412 Bug ID: 93412 Summary: [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_add_overflow() at -Og Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 47702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47702&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Og testcase.c testcase.c: In function 'foo': testcase.c:11:1: error: unrecognizable insn: 11 | } | ^ (insn 98 97 38 2 (parallel [ (set (reg:CCO 17 flags) (eq:CCO (plus:TI (plus:TI (ltu:TI (reg:CC 17 flags) (const_int 0 [0])) (sign_extend:TI (reg:DI 37 r9 [+8 ]))) (sign_extend:TI (const_int 0 [0]))) (sign_extend:TI (plus:DI (plus:DI (ltu:DI (reg:CC 17 flags) (const_int 0 [0])) (reg:DI 37 r9 [+8 ])) (const_int 0 [0]) (set (reg:DI 37 r9 [+8 ]) (plus:DI (plus:DI (ltu:DI (reg:CC 17 flags) (const_int 0 [0])) (reg:DI 37 r9 [+8 ])) (const_int 0 [0]))) ]) "testcase.c":9:7 -1 (nil)) during RTL pass: split2 testcase.c:11:1: internal compiler error: in extract_insn, at recog.c:2294 0x700160 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.c:108 0x7001e3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.c:116 0x6eef6e extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.c:2294 0xfe3574 extract_insn_cached(rtx_insn*) /repo/gcc-trunk/gcc/recog.c:2183 0xd00282 cleanup_subreg_operands(rtx_insn*) /repo/gcc-trunk/gcc/final.c:3312 0xfdfe3f split_insn /repo/gcc-trunk/gcc/recog.c:2920 0xfe6507 split_all_insns() /repo/gcc-trunk/gcc/recog.c:2988 0xfe65b8 execute /repo/gcc-trunk/gcc/recog.c:3887 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-6200-ge3fe0070c18-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r10-6200-ge3fe0070c18-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200124 (experimental) (GCC)
[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92989 --- Comment #3 from Dragan Mladjenovic --- Created attachment 47703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47703&action=edit Reproducer for additional failure Toolchain build seems to still contain this failure that can be reproduced with: $ mipsisa64-elf-gcc -std=gnu++11 -O2 -c -x c++ cxx11-locale-inst.i -minterlink-mips16 -mips16 -mips32r2 -mabi=32 -o cxx11-locale-inst.o
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jonathan Wakely --- Fixed for gcc-9 as well, please let me know if you see any more build issues here.
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947
--- Comment #17 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e2bcf65feea9590e6f260862b3c740b5e803f851
commit r9-8174-ge2bcf65feea9590e6f260862b3c740b5e803f851
Author: Jonathan Wakely
Date: Fri Jan 24 11:13:55 2020 +
libstdc++: Simplify makefile rule for largefile-config.h (PR91947)
The previous rule could leave an incomplete file if the build was
interrupted, which would then not be remade if make was run again.
This makes the rule more robust by writing to a temporary file and only
moving it into place as the final step. It also simplifies the rule so
that only the essential macro definitions are written to the file, not
the explanatory comments and commented out #undef lines.
Also, the macro for enabling LFS on Mac OS X 10.5 is now set
unconditionally, which is a bug fix from upstream autoconf.
Backport from mainline
2020-01-23 Jonathan Wakely
PR libstdc++/91947
* include/Makefile.am (${host_builddir}/largefile-config.h): Simplify
rule.
* include/Makefile.in: Regenerate.
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947 --- Comment #19 from Eric Botcazou --- > Fixed for gcc-9 as well, please let me know if you see any more build issues > here. Sure, thanks for the quick resolution!
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 Andrew Stubbs changed: What|Removed |Added CC||ams at gcc dot gnu.org --- Comment #1 from Andrew Stubbs --- Please don't try x32. It might have previously built, but it does not work. In order for offloading to work it is necessary that both CPU and GPU use the exact same type layout. Since the GPU compiler is using x86_64 compatible types it is incompatible with x86_32. We should probably find a nicer way to not build. :-(
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 markeggleston at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |markeggleston at gcc dot gnu.org --- Comment #5 from markeggleston at gcc dot gnu.org --- (In reply to Steve Kargl from comment #4) > On Thu, Jan 23, 2020 at 03:37:04PM +, markeggleston at gcc dot gnu.org > wrote: > > > > If the parameter attribute is removed or a non zero sized array is used, the > > ICE does not occur. > > > > The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref > > structure > > has been created and has the type REF_INQUIRY. If the primary expression has > > been passed in is EXPR_CONSTANT the check is done. When the ICE occurs the > > type > > is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used > > for > > the inquiry type instead of being 2 (INQUIRY_KIND) it is random > > e.g.73176720. > > > > Not quite, right. If you have > >complex, parameter :: a(1) = 0 >integer b >data b/a%kind% > > then at line 2337 in primary.c > >gfc_simplify_expr (primary, 0); > > collapses primary to an EXPR_CONSTANT, and then things seem to work. > > If you have > >complex, parameter :: a(0) = 0 >integer b >data b/a%kind% > > then "gfc_simplify_expr (primary, 0)" does not collapse primary > to EXPR_CONSTANT as it seems gfc_simplify_expr does not handle > zero size arrays (as there is nothing to simplify!). gfortran gfc_simplify_expr calls simplify_parameter_variable which for zero size arrays it creates a new gfc_expr structure with the expr_type set to EXPR_ARRAY and replaces primary. When primary is replaced its chain of ref structures is deleted so tmp->u.i is invalid causing the ICE the following lines are never reached: > then enters the switch statement and get to lines 2384-2385 > >primary->ts.type = BT_INTEGER; >primary->ts.kind = gfc_default_integer_kind; > > This just resets a part of primary, but it does not fix up > it up correctly. Likely, need to check for zero size > arrays do extra work. I have modified gfc_simplify_expr: --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -2069,8 +2069,13 @@ simplify_parameter_variable (gfc_expr *p, int type) e->value.constructor = NULL; e->shape = gfc_copy_shape (p->shape, p->rank); e->where = p->where; - gfc_replace_expr (p, e); - return true; + e->ref = gfc_copy_ref (p->ref); + t = gfc_simplify_expr (e, type); + if (t && !e->ref) + gfc_replace_expr (p, e); + else + gfc_free_expr (e); + return t; } e = gfc_copy_expr (p->symtree->n.sym->value); This results in primary being reduced to a EXPR_CONSTANT just like it is for non-zero length arrays. I've checked the 8 and 9 branches, 8 does not support this syntax and 9.2 behaves differently: program p real, parameter :: a(0) = 0.5 write(*,*) a%kind end compiles but the output is: 0.5 and program p real, parameter :: a(1) = 0.5 write(*,*) a%kind end fails to compile with an ICE. I'll investigate these further and ad either 1 or 2 new PRs. I'm now getting failures for several test cases in gfortran.dg, more work to do...
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- About to post a patch.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
Untested:
diff --git a/libgomp/configure b/libgomp/configure
index 04a6fd96610..ee1bbe6a0a8 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15322,3 +15322,3 @@ rm -f core conftest.err conftest.$ac_objext \
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_HSA=0
@@ -15362,3 +15362,3 @@ rm -f core conftest.err conftest.$ac_objext \
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_GCN=0
diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac
index 9a424aa1c9c..fc91702a434 100644
--- a/libgomp/plugin/configfrag.ac
+++ b/libgomp/plugin/configfrag.ac
@@ -213,3 +213,3 @@ if test x"$enable_offload_targets" != x; then
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_HSA=0
@@ -253,3 +253,3 @@ if test x"$enable_offload_targets" != x; then
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_GCN=0
[Bug c++/93413] New: Destructor definition not found during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Bug ID: 93413
Summary: Destructor definition not found during constant
evaluation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
struct Base {
constexpr virtual ~Base(){}
};
struct Derived: Base {};
constexpr Derived d;
Destructor for the `Derived` should be implicitly defined. However the above
snippet produces error message on GCC-10 with -std=c++2a flag: `error: 'virtual
constexpr Derived::~Derived()' used before its definition`.
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- (In reply to Rainer Orth from comment #3) > The new test FAILs on Solaris/SPARC, both 32 and 64-bit: > > +FAIL: gcc.dg/analyzer/pr93375.c (test for warnings, line 14) > +FAIL: gcc.dg/analyzer/pr93375.c (test for excess errors) > > Excess errors: > /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/pr93375.c:14:3: > warning: use of NULL 'rl' where non-null expected [CWE-690] > [-Wanalyzer-null-argument] Same thing on arm-linux-gnueabi[hf] when forcing eg. -march=armv5t
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #9 from David Malcolm --- (In reply to Iain Sandoe from comment #8) > (In reply to David Malcolm from comment #7) > > (In reply to r...@cebitec.uni-bielefeld.de from comment #6) > > [...] > > > On Solaris (both sparc and x86), all analyzer testsuite failures are > > > gone. > > > > Thanks. > > > > I'll go ahead and mark this as resolved. Please reopen if there are any > > other failures (apart from the pattern-test-2.c issue, which is PR > > analyzer/93291). > > Hi David, > Things are much improved on Darwin, but certainly not (yet) all fixed (see > https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01146.html and the next > few entries). Thanks for the update. > * analyzer/abort.c fails everywhere on Darwin with: > > /src-local/gcc-master/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: > UNKNOWN > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 14) > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 31) > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 47) > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 60) > FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71) > FAIL: gcc.dg/analyzer/abort.c (test for excess errors) > Excess errors: > /src-local/gcc-master/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: > UNKNOWN Looks like PR 93367, which should be fixed by r10-6195-ga0b935ac66bc9804b0864151e5f1bfde5ac1ddeb. > * analyzer/dot-output.c: fails on 32bit HOSTs (x86 and PPC) with: > > Warning: dot-output.c.state-purge.dot:11: string ran past end of line > Error: dot-output.c.state-purge.dot:12: syntax error near line 12 > context: >>> ' <<< _5' not needed here > Warning: dot-output.c.state-purge.dot:34: string ran past end of line > Warning: dot-output.c.state-purge.dot:45: string ran past end of line > Looks like PR 93293. What version of GraphViz do you have installed? > * analyzer/malloc-1.c: fails on x86_64 HOSTs with: > > PASS: gcc.dg/analyzer/malloc-1.c (test for warnings, line 393) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 417) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 418) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 425) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 429) > XFAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 445) > PASS: gcc.dg/analyzer/malloc-1.c (test for warnings, line 453) I haven't seen failures before. It looks like memset in your hasn't been marked with __attribute__ ((__nonnull__)) on its first param, which the tests are implicitly assuming. > powerpc-darwin9 (32b host) has a couple of additional fails, including the > pattern-test-2.c case. > > Do you want me to re-open this or open one or more new ones? Please open a new one for the malloc-1.c issue.
[Bug c++/93414] New: Bad diagnostics for dynamic_cast during constant evaluation: implementation details leak out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93414
Bug ID: 93414
Summary: Bad diagnostics for dynamic_cast during constant
evaluation: implementation details leak out
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example that attempts to throw a std::bad_cast:
struct Base {
constexpr virtual ~Base(){}
};
struct Derived: Base {
constexpr ~Derived(){}
};
constexpr const Derived& cast(const Base& b) {
return dynamic_cast(b); // error!
}
auto test() {
static constexpr Base b;
constexpr auto res = cast(b);
return res;
}
The error message is following:
: In function 'constexpr const Derived& cast(const Base&)':
:10:42: error: call to non-'constexpr' function 'void*
__cxa_bad_cast()'
10 | return dynamic_cast(b); // error: call to
non-'constexpr' function 'void* __cxa_bad_cast()'
That's not informative: users usually know nothing about __cxa_bad_cast
Please change the error message to something more informative, for example
"During constexpr evaluation attempt to cast a variable `b` with typeid(b) ==
typeid(Base) to `Derived` was detected"
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #10 from David Malcolm --- (In reply to David Malcolm from comment #9) > (In reply to Iain Sandoe from comment #8) [...] > I haven't seen failures before. ^ "these failures", I meant to say [...] > > > > Do you want me to re-open this or open one or more new ones? > > Please open a new one for the malloc-1.c issue. ..."and for any other new ones", I meant to say Thanks
[Bug c++/93415] New: Previous declaration of template without default arguments leads to incorrect overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93415
Bug ID: 93415
Summary: Previous declaration of template without default
arguments leads to incorrect overload resolution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
#include
template
void f (int);
template
void f (int)
{
std::cout << "correct - int\n";
}
template
void f (char)
{
std::cout << "wrong - char\n";
}
int main ()
{
f (0);
return 0;
}
The above program prints "wrong - char" with gcc, however just removing
declartion of `f` without default arguments leads to expected result. It is
very annoying issue because do-nothing forward declarations may lead to
unexpected hard to find bugs. Other compilers seem to handle this case
properly.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 --- Comment #3 from Matthias Klose --- this is needed for the bootstrap, you have to build the plugin for all multilibs, although it's discarded on install.
[Bug c++/93414] Bad diagnostics for dynamic_cast during constant evaluation: implementation details leak out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93414 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-24 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine. Users weren't supposed to see that message.
[Bug c/91113] add declare_simd_variant attribute support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91113 nsz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from nsz at gcc dot gnu.org --- i think this will have to be done differently (the attribute syntax).
[Bug bootstrap/93416] New: [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93416 Bug ID: 93416 Summary: [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at ubuntu dot com Target Milestone: --- seen with 20200124 on s390x-linux-gnu. It tells it cannot be reproduced, but I see it repeatedly. gcc configured with Configured with: -v --enable-languages=c,c++,go,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch=z196 --with-long-double-128 --enable-multilib --enable-checking=yes --build=s390x-linux-gnu --host=s390x-linux-gnu --target=s390x-linux-gnu [...] echo timestamp > s-macro_list /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests cc1: internal compiler error: in tree_cmp, at analyzer/region-model.cc:1851 /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests 0x3ffa06ab3a5 __libc_start_main /build/glibc-MXXdq1/glibc-2.29/csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. cc1plus: internal compiler error: in tree_cmp, at analyzer/region-model.cc:1851 0x3ff848ab3a5 __libc_start_main /build/glibc-MXXdq1/glibc-2.29/csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. make[5]: *** [../../src/gcc/c/Make-lang.in:124: s-selftest-c] Error 1 make[5]: *** Waiting for unfinished jobs The bug is not reproducible, so it is likely a hardware or OS problem. make[5]: *** [../../src/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 1 rm gcov.pod fsf-funding.pod lto-dump.pod gfdl.pod gpl.pod cpp.pod gccgo.pod gcc.pod gdc.pod gcov-dump.pod gfortran.pod gcov-tool.pod make[5]: Leaving directory '/<>/build/gcc' make[4]: *** [Makefile:4746: all-stage2-gcc] Error 2 make[4]: Leaving directory '/<>/build' make[3]: *** [Makefile:24566: stage2-bubble] Error 2 make[3]: Leaving directory '/<>/build' make[2]: *** [Makefile:24770: bootstrap] Error 2 make[2]: Leaving directory '/<>/build'
[Bug target/93417] New: PPC: Support the "Flag Output Operands" so inline-asm can avoid having to copy CRx to GPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93417 Bug ID: 93417 Summary: PPC: Support the "Flag Output Operands" so inline-asm can avoid having to copy CRx to GPR Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: memmerto at ca dot ibm.com Target Milestone: --- From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 > If PowerPC back-end supported the "Flag Output Operands" part > if GCC's inline-asm, you could use that to do the correct thing. > But sadly PowerPC does not currently. > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands
[Bug target/93177] PPC: Missing many useful platform intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 --- Comment #14 from Matt Emmerton --- I'd like to thank everyone for the great discussion so far. Here's a summary of where we are at this point. 1) sync intrinsics Useful, but with caveats. 2) cache prefetch intrinsics Implemented via __builtin_prefetch() 3) larx/stcx intrinsics Useful, but with caveats. Improvements to stcx CR handling, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93417 4) streaming cache prefetch intrinsics See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93408
[Bug regression/93418] New: GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Bug ID: 93418
Summary: GCC incorrectly constant propagates _mm_sllv/srlv/srav
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: husseydevin at gmail dot com
Target Milestone: ---
Regression starting in GCC 9
Currently, GCC constant propagates the AVX2 _mm_sllv family with constant
amounts to only shift by the first element instead of all elements
individually.
#include
#include
// force -O0
__attribute__((__optimize__("-O0")))
void unoptimized() {
__m128i vals = _mm_set1_epi32(0x);
__m128i shifts = _mm_setr_epi32(16, 31, -34, 3);
__m128i shifted = _mm_sllv_epi32(vals, shifts);
printf("%08x %08x %08x %08x\n", _mm_extract_epi32(shifted, 0),
_mm_extract_epi32(shifted, 1), _mm_extract_epi32(shifted, 2),
_mm_extract_epi32(shifted, 3));
}
// force -O3
__attribute__((__optimize__("-O3")))
void optimized() {
__m128i vals = _mm_set1_epi32(0x);
__m128i shifts = _mm_setr_epi32(16, 31, -34, 3);
__m128i shifted = _mm_sllv_epi32(vals, shifts);
printf("%08x %08x %08x %08x\n", _mm_extract_epi32(shifted, 0),
_mm_extract_epi32(shifted, 1), _mm_extract_epi32(shifted, 2),
_mm_extract_epi32(shifted, 3));
}
int main() {
printf("Without optimizations (correct result):\t");
unoptimized();
printf("With optimizations (incorrect result):\t");
optimized();
}
I would expect this code to emit the following:
Without optimizations (correct result): 8000 fff8
With optimizations (incorrect result): 8000 fff8
Clang and GCC < 9 exhibit the first output, but 9.1 and later
However, I get this output on GCC 9 and later:
Without optimizations (correct result): 8000 fff8
With optimizations (incorrect result):
Godbolt link: https://gcc.godbolt.org/z/oC3Psp
[Bug target/93418] [10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Andrew Pinski changed: What|Removed |Added Component|regression |target Target Milestone|--- |10.0 Summary|GCC incorrectly constant|[10 Regression] GCC |propagates |incorrectly constant |_mm_sllv/srlv/srav |propagates ||_mm_sllv/srlv/srav
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 --- Comment #6 from Steve Kargl --- On Fri, Jan 24, 2020 at 12:36:45PM +, markeggleston at gcc dot gnu.org wrote: > gfc_simplify_expr calls simplify_parameter_variable which for zero size > arrays it creates a new gfc_expr structure with the expr_type set to > EXPR_ARRAY > and replaces primary. When primary is replaced its chain of ref structures is > deleted so tmp->u.i is invalid causing the ICE the following lines are never > reached: The lines are reached in my debugging sessions. :-) I bootstrap with --enable-checking, which might prevent the ICE issue. > > then enters the switch statement and get to lines 2384-2385 > > > >primary->ts.type = BT_INTEGER; > >primary->ts.kind = gfc_default_integer_kind; > > > > This just resets a part of primary, but it does not fix up > > it up correctly. Likely, need to check for zero size > > arrays do extra work. > > I have modified gfc_simplify_expr: I'm beginning to think that calling gfc_simplify_expr may not be correct, here. But, don't have time to investigate more.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-24
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
From .ccp1:
Visiting statement:
_17 = VIEW_CONVERT_EXPR(shifts_13);
which is likely CONSTANT
Match-and-simplified VIEW_CONVERT_EXPR(shifts_13) to { 16, 31,
-34, 3 }
Lattice value changed to CONSTANT { 16, 31, -34, 3 }. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_18 = VIEW_CONVERT_EXPR(vals_11);
which is likely CONSTANT
Match-and-simplified VIEW_CONVERT_EXPR(vals_11) to { -1, -1, -1,
-1 }
Lattice value changed to CONSTANT { -1, -1, -1, -1 }. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_19 = __builtin_ia32_psllv4si (_18, _17);
which is likely CONSTANT
Lattice value changed to CONSTANT { -65536, -65536, -65536, -65536 }. Adding
SSA edges to worklist.
marking stmt to be not simulated again
[Bug preprocessor/93419] New: __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
Bug ID: 93419
Summary: __has_attribute(ifunc) false positive on hurd and
kfreebsd
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: fabian-gcc at kloetzl dot info
Target Milestone: ---
Hi all,
Hereby I am forwarding a bug I filed against Debian [1]. One of my packages
there failed to build on hurd-i386 and kfreebsd-* due to unsupported ifuncs.
However, I had that code guarded by __has_attribute(ifunc) which,
unfortunately, evaluates to 1 on said platforms. A minimal testcase is given
below.
Best,
Fabian
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945133
-
#include
int main() {
return 0;
}
#if __has_attribute(ifunc)
typedef void (fntype)(void);
fntype* fn_select(void) {
return NULL;
}
void fn(void) __attribute__((ifunc("fn_select")));
#endif
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #2 from Andrew Pinski --- The bug is most likely inside ix86_fold_builtin.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 --- Comment #1 from Andrew Pinski --- __has_attribute(ifunc) is true as the attribute is supported all the way through the compiler up to the point where it gets emitted. Really __has_attribute is a bad execuse for not doing proper feature testing in my mine.
[Bug target/13721] SEGV on inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13721 --- Comment #12 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:64c9f2d9972ad359a32f0a97ee0a806c2532db15 commit r10-6207-g64c9f2d9972ad359a32f0a97ee0a806c2532db15 Author: Jeff Law Date: Fri Jan 24 08:57:46 2020 -0700 Emit reasonable diagnostic rather than ICE on invalid ASM on H8 port PR target/13721 * config/h8300/h8300.c (h8300_print_operand): Only call byte_reg for REGs. Call output_operand_lossage to get more reasonable diagnostics. PR target/13721 * gcc.target/h8300/pr13721.c: New test.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 --- Comment #2 from Andrew Pinski --- I think the docs are clear here too: The special operator __has_attribute (operand) may be used in ‘#if’ and ‘#elif’ expressions to test whether the attribute referenced by its operand is recognized by GCC. CUT --- __has_attribute just says GCC recognizes the attribute which is true, ifunc is recognized and is basically supported inside gcc until the very end of the compiler. So I want to say this is an invalid bug report ...
[Bug target/13721] SEGV on inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13721 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #13 from Jeffrey A. Law --- Yes, using output_operand_lossage was the right thing to do here. I've done that in the most obvious places where we called byte_reg.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 --- Comment #3 from kloetzl --- Hm, I feared that this would be the answer I would get. This makes GCCs __has_attribute much less useful than Clangs version where the docs state: “This function-like macro takes a single identifier argument that is the name of a GNU-style attribute. It evaluates to 1 if the attribute is supported by the current compilation target, or 0 if not.”
[Bug c++/93420] New: Deducing "T C::* const&" from a non-const pointer-to-member-function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93420
Bug ID: 93420
Summary: Deducing "T C::* const&" from a non-const
pointer-to-member-function fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct S {};
template
void check(T C::* const&);
int (S::*f)();
using t = decltype(check(f));
Rejected by GCC:
:8:27: error: no matching function for call to 'check(int (S::*&)())'
8 | using t = decltype(check(f));
| ^
:4:6: note: candidate: 'template void check(T C::*
const&)'
4 | void check(T C::* const&);
| ^
:4:6: note: template argument deduction/substitution failed:
:8:27: note: types 'T C::* const' and 'int (S::*)()' have
incompatible cv-qualifiers
8 | using t = decltype(check(f));
| ^
This appears to be the cause of PR69243, which was worked around in the
library.
[Bug analyzer/93349] ICE: verify_gimple failed (error: location references block not in block tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93349 --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01673.html
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279 --- Comment #5 from Marek Polacek --- Since r9-6405-gbddee796d0b4800b5ac3d7e7e9e315c23799424d, when we see in a lambda a use of an operator that might be overloaded, we do name lookup and save it away in an internal attribute on the lambda call operator. Here we have a (generic) lambda and the * operator, so we stash operator* -> OVERLOAD [template_decl] into the attribute. Then push_operator_bindings pushes it to the function parameter binding level using push_local_binding. When we instantiate_decl the function operator* we end up substituting the m * l expr. Then build_x_binary_op builds it, it calls build_new_op_1 which will invoke add_operator_candidates. That will add the operator* TEMPLATE_DECL stashed above into the candidate set. It's a template and we try to deduce the template arguments in fn_type_unification. We have a template parameter of type B::f, and we will tsubst its template arguments = E. This will wind up lookup_template_class (E, ) which calls coerce_template_parms. So we convert_template_argument: #3 0x009a0fdf in maybe_constant_value (t=, decl=, manifestly_const_eval=true) at /home/mpolacek/src/gcc/gcc/cp/constexpr.c:6596 #4 0x00bad57a in convert_nontype_argument (type=, expr=, complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:7116 #5 0x00bb1cc8 in convert_template_argument (parm=, arg=, args=, complain=0, i=1, in_decl=) at /home/mpolacek/src/gcc/gcc/cp/pt.c:8350 And so maybe_constant_value gets a template_parm_index. But processing_template_decl is 0 so this check if (!is_nondependent_constant_expression (t)) in maybe_constant_value won't work: value_dependent_expression_p always returns false when !processing_template_decl. So the template_parm_index winds up going to the constexpr machinery and that ICEs. I would think we need ++processing_template_decl; ... --processing_template_decl; somewhere, but can't find the right spot.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- What does the build failure look like? Quoting from What we need in https://gcc.gnu.org/bugs: Please include all of the following items, the first three of which can be obtained from the output of gcc -v: ... the compiler output (error messages, warnings, etc.); and
[Bug libstdc++/93421] New: futex.cc use of futex syscall is not time64-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421 Bug ID: 93421 Summary: futex.cc use of futex syscall is not time64-compatible Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 47704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47704&action=edit simple fix, not necessarily right for upstream This code directly passes a userspace timespec struct to the SYS_futex syscall, which does not work if the userspace type is 64-bit but the syscall expects legacy 32-bit timespec. I'm attaching the patch we're using in musl-cross-make to fix this. It does not attempt to use the SYS_futex_time64 syscall, since that would require fallback logic with cost tradeoffs for which to try first, and since the timeout is relative and therefore doesn't even need to be 64-bit. Instead it just uses the existence of SYS_futex_time64 to infer that the plain SYS_futex uses a pair of longs, and converts the relative timestamp into that. This assumes that any system where the libc timespec type has been changed for time64 will also have had its headers updated to define SYS_futex_time64. Error handling for extreme out-of-bound values should probably be added.
[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470 Jeffrey A. Law changed: What|Removed |Added Target Milestone|10.0|11.0 --- Comment #4 from Jeffrey A. Law --- Yes, the loop PHI is where things start, but the PHI in the latch block is just as problematical it not more. It's the use in the latch PHI that uninit.c considers unguarded. We could duplicate the latch block (thus creating two backedges to the top of the loop). Of course this mucks up the loop structures to some degree, so it's not a great solution. We could unroll the loop which ought to untangle things enough, but that's a codesize regression and just twiddling the loop bounds would be enough to bring the warning back, so I consider this a non-starter. Peeling the first iteration has the same effect as unrolling on this specific test and I think would resolve it. Peeling the first iteration would also work if the loop bounds were different. Jump threading often has the same effect as peeling off an iteration. DOM3 discovers the opportunity, but doesn't actually thread the jump presumably because doing so will muck up the loop structure. I looked at Bin's recent work hoping it might be enough to help uninit.c realize the use is guarded, but it isn't. It may be extendable to handle this case though. Unsure. Given we don't really have a viable path forward yet, I'm going to punt this to 11.
[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-24 Ever confirmed|0 |1
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:28a5d5c365044710ba32510b9bec67dd40562154 commit r10-6210-g28a5d5c365044710ba32510b9bec67dd40562154 Author: Jason Merrill Date: Thu Jan 23 15:45:36 2020 -0500 c++: Unshare expressions from constexpr cache. Another place we need to unshare cached expressions. PR c++/92852 - ICE with generic lambda and reference var. * constexpr.c (maybe_constant_value): Likewise.
[Bug fortran/93422] New: Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422 Bug ID: 93422 Summary: Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code results in a bogus error (using git commit 472dc648ce3e7661762931d584d239611ddca964) claiming a pointer attribute mismatch between the function result as defined in the module and submodule: module t type :: a contains procedure :: p => ap end type a type, extends(a) :: b contains procedure :: p => bp end type b type :: c end type c type, extends(c) :: d end type d interface module function bp(s) class(b), intent(inout) :: s class(d), pointer :: bp end function end interface contains function ap(s) class(a), intent(inout) :: s class(d), pointer :: ap end function ap end module t submodule (t) ts contains function bp(s) class(d), pointer :: bp class(b), intent(inout) :: s end function bp end submodule ts $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c test4.mod.F90 -o test4.mod.o test4.mod.F90:35:12: 35 | submodule (t) ts |1 Error: Result mismatch for the overriding procedure 'p' at (1): POINTER attribute mismatch in function result test4.mod.F90:39:2: 39 | function bp(s) | 1 Error: POINTER attribute mismatch in function result between the MODULE PROCEDURE declaration in MODULE 't' and the declaration at (1) in (SUB)MODULE 'ts' The code compiles successfully if the "pointer" attribute is removed, or if the function in the submodule is declared using the "module procedure" approach instead of explicitly (re)defining its interface. It also compiles successfully using ifort 18.0.1.
[Bug fortran/93423] New: ICE on invalid with argument list for module procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423 Bug ID: 93423 Summary: ICE on invalid with argument list for module procedure Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following invalid code results in an ICE (using git commit 472dc648ce3e7661762931d584d239611ddca964): module t type :: b contains procedure :: p => bp end type b interface module function bp(s) class(b), intent(inout) :: s integer, pointer :: bp end function end interface end module t submodule (t) ts contains module procedure bp(s) end procedure bp end submodule ts $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c test2.mod.F90 -o test2.mod.o test2.mod.F90:21:19: 21 | module procedure bp(s) | 1 Error: MODULE PROCEDURE at (1) must be in a generic module interface test2.mod.F90:22:5: 22 | end procedure bp | 1 Error: Expecting END SUBMODULE statement at (1) *** glibc detected *** /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951: free(): invalid pointer: 0x03e2fa70 *** === Backtrace: = /home/abenson/Galacticus/Tools/lib/libc.so.6(+0x71776)[0x7fe72592a776] /home/abenson/Galacticus/Tools/lib/libc.so.6(cfree+0x6c)[0x7fe72592f49c] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6b4e] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6c59] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6276] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6630] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z17gfc_symbol_done_2v+0x54)[0x8a8314] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z10gfc_done_2v+0x9)[0x83e559] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x85a9a4] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z14gfc_parse_filev+0xa14)[0x8675d4] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8b7570] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0xe1b484] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_ZN6toplev4mainEiPPc+0x7ad)[0xe1db0d] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(main+0x2f)[0x183b47f] /home/abenson/Galacticus/Tools/lib/libc.so.6(__libc_start_main+0xfd)[0x7fe7258d7d0d] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x7c5f21] === Memory map: 0040-025c3000 r-xp 09:06 39587037 /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951 027c3000-027d3000 rw-p 021c3000 09:06 39587037 /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951 027d3000-0292d000 rw-p 00:00 0 03d87000-03e4a000 rw-p 00:00 0 [heap] 3c4540-3c4542 r-xp 09:01 1703950 /lib64/ld-2.12.so 3c4561f000-3c4562 r--p 0001f000 09:01 1703950 /lib64/ld-2.12.so 3c4562-3c45621000 rw-p 0002 09:01 1703950 /lib64/ld-2.12.so 3c45621000-3c45622000 rw-p 00:00 0 7fe72000-7fe720021000 rw-p 00:00 0 7fe720021000-7fe72400 ---p 00:00 0 7fe725347000-7fe72535e000 r-xp 09:06 38928531 /home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1 7fe72535e000-7fe72555d000 ---p 00017000 09:06 38928531 /home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1 7fe72555d000-7fe72555e000 rw-p 00016000 09:06 38928531 /home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1 7fe72555e000-7fe7258b9000 rw-p 00:00 0 7fe7258b9000-7fe725a18000 r-xp 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so 7fe725a18000-7fe725c18000 ---p 0015f000 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so 7fe725c18000-7fe725c1c000 r--p 0015f000 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so 7fe725c1c000-7fe725c1d000 rw-p 00163000 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.1
[Bug fortran/93424] New: ICE on valid with pointer result from submodule function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424 Bug ID: 93424 Summary: ICE on valid with pointer result from submodule function Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following invalid code results in an ICE (using git commit 472dc648ce3e7661762931d584d239611ddca964): module t type :: a contains procedure :: p => ap end type a type, extends(a) :: b contains procedure :: p => bp end type b type :: c end type c interface module function bp(s) class(b), intent(inout) :: s class(c), pointer :: bp end function end interface contains function ap(s) class(a), intent(inout) :: s class(c), pointer :: ap end function ap end module t submodule (t) ts contains function bp(s) class(b), intent(inout) :: s class(c), pointer :: bp end function bp end submodule ts $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c test3.mod.F90 -o test3.mod.o f951: internal compiler error: Segmentation fault 0xe1b2bf crash_signal ../../gcc-git/gcc/toplev.c:328 0x7fc2247331ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x80cc31 compare_rank ../../gcc-git/gcc/fortran/interface.c:776 0x80cc31 compare_rank ../../gcc-git/gcc/fortran/interface.c:766 0x80ef55 gfc_check_result_characteristics(gfc_symbol*, gfc_symbol*, char*, int) ../../gcc-git/gcc/fortran/interface.c:1556 0x814ae2 gfc_check_typebound_override(gfc_symtree*, gfc_symtree*) ../../gcc-git/gcc/fortran/interface.c:4799 0x86fd0d resolve_typebound_procedure ../../gcc-git/gcc/fortran/resolve.c:14002 0x8a0769 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4178 0x8785bc resolve_typebound_procedures ../../gcc-git/gcc/fortran/resolve.c:14053 0x8785bc resolve_fl_derived ../../gcc-git/gcc/fortran/resolve.c:14829 0x8751a7 resolve_symbol ../../gcc-git/gcc/fortran/resolve.c:15199 0x8a0722 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4172 0x882893 resolve_types ../../gcc-git/gcc/fortran/resolve.c:17123 0x8741fc gfc_resolve(gfc_namespace*) ../../gcc-git/gcc/fortran/resolve.c:17238 0x8741fc gfc_resolve(gfc_namespace*) ../../gcc-git/gcc/fortran/resolve.c:17219 0x8670b7 gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6446 0x8b756f gfc_be_parse_file ../../gcc-git/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug fortran/93424] ICE on valid with pointer result from submodule function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424 --- Comment #1 from Andrew Benson --- Correction: The above code is valid (not invalid as I stated in the description) as far as I can tell.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316
--- Comment #11 from David Edelsohn ---
I continue to see setjmp failures on AIX.
FAIL: gcc.dg/analyzer/setjmp-7a.c expected multiline pattern lines 41-110 not
found:
FAIL: gcc.dg/analyzer/setjmp-7a.c (test for excess errors)
Excess errors:
NN | longjmp (env, 1); /* { dg-warning "leak of 'ptr'" } */
FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-8.c (test for warnings, line 29)
FAIL: gcc.dg/analyzer/setjmp-8.c expected multiline pattern lines 40-108 not
found:
FAIL: gcc.dg/analyzer/setjmp-8.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | longjmp (env, 0);
| ^~~~
ranges offset out of range
FAIL: gcc.dg/analyzer/setjmp-9.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-9.c (test for warnings, line 31)
FAIL: gcc.dg/analyzer/setjmp-9.c expected multiline pattern lines 42-110 not
found:
FAIL: gcc.dg/analyzer/setjmp-9.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-9.c:17:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | longjmp (env, unknown_val);
| ^~
ranges offset out of range
FAIL: gcc.dg/analyzer/setjmp-3.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-3.c (test for warnings, line 28)
FAIL: gcc.dg/analyzer/setjmp-3.c expected multiline pattern lines 39-107 not
found:
FAIL: gcc.dg/analyzer/setjmp-3.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-3.c:14:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | longjmp (env, 1);
| ^~~~
ranges offset out of range
FAIL: gcc.dg/analyzer/setjmp-4.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-4.c (test for warnings, line 29)
FAIL: gcc.dg/analyzer/setjmp-4.c expected multiline pattern lines 34-107 not
found:
FAIL: gcc.dg/analyzer/setjmp-4.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-4.c:12:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | foo (x);
| ^~~
ranges offset out of range
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #12 from David Malcolm --- (In reply to David Edelsohn from comment #11) > I continue to see setjmp failures on AIX. > [...] > FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error) > during IPA pass: analyzer > /nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3: > interna > l compiler error: in as_a, at is-a.h:197 >NN | longjmp (env, 0); > | ^~~~ > ranges offset out of range David, which version are you testing? This looks reminiscent of PR 93378, which I fixed in r10-6154-g597e403d6dbb44315f33fb2b5bb0ca4946a4a1e1.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #13 from David Malcolm --- (In reply to David Malcolm from comment #12) > (In reply to David Edelsohn from comment #11) > > I continue to see setjmp failures on AIX. > > > [...] > > FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error) > > during IPA pass: analyzer > > /nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3: > > interna > > l compiler error: in as_a, at is-a.h:197 > >NN | longjmp (env, 0); > > | ^~~~ > > ranges offset out of range > > David, which version are you testing? This looks reminiscent of PR 93378, > which I fixed in r10-6154-g597e403d6dbb44315f33fb2b5bb0ca4946a4a1e1. Well, r10-6153-gfd9982bb0051d1a678191b684bb907d1ac177991 (that other commit is a fix for me messing up the testcase)
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #14 from David Edelsohn --- Compiler version: 10.0.1 20200124 (experimental) [src revision 96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 --- Comment #6 from David Binderman --- I can confirm this is still going wrong in a raspberry pi cross compiler dated 20200123.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7175893ad8010df1270af884a1810476e51a8cd9 commit r8-9953-g7175893ad8010df1270af884a1810476e51a8cd9 Author: Jason Merrill Date: Thu Jan 23 15:45:36 2020 -0500 c++: Unshare expressions from constexpr cache. Another place we need to unshare cached expressions. PR c++/92852 - ICE with generic lambda and reference var. * constexpr.c (maybe_constant_value): Likewise.
[Bug c++/92778] [8/9 regression] ICE: Illegal instruction signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778 --- Comment #6 from Hannes Hauswedell --- Ok, the ICE on Linux is a different one. This particular ICE happens only on FreeBSD. I have rebuilt GCC9 from source with fullbootstrap and without any -march settings. The problem remains. What can I do to further narrow this down?
[Bug c++/93425] New: Template parameter deduction failure when template parameters have template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425
Bug ID: 93425
Summary: Template parameter deduction failure when template
parameters have template template parameter
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
The following code fails to compile:
template< typename T >
struct plus {};
template< typename Q >
struct test
{
template< template< typename > class BinaryFunT, typename NumberT >
static void test_impl(NumberT n)
{
}
static void test_arith()
{
test_impl< plus >(10);
}
};
$ g++ -O3 -c -o test.o test.cpp
test.cpp: In static member function ‘static void test::test_arith()’:
test.cpp:14:29: error: no matching function for call to
‘test::test_impl(int)’
14 | test_impl< plus >(10);
| ^
test.cpp:8:17: note: candidate: ‘template
template class BinaryFunT, class NumberT>
template template class BinaryFunT, class NumberT> static void
test::test_impl(NumberT)’
8 | static void test_impl(NumberT n)
| ^
test.cpp:8:17: note: template argument deduction/substitution failed:
test.cpp:14:29: note: mismatched types ‘NumberT’ and ‘int’
14 | test_impl< plus >(10);
| ^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
The same code compiles fine with gcc 8.3.0 and clang 9. Compilation succeeds if
I remove the template template parameter from test_impl definition and
invokation.
Note also how gcc 9 messes up the template parameters lists in the error
message. If this is an unrelated problem, let me know if I should file a
separate bug to fix this.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a4b7cf5865823df4b4df1d840d692dfc83fd0672 commit r9-8175-ga4b7cf5865823df4b4df1d840d692dfc83fd0672 Author: Jason Merrill Date: Thu Jan 23 15:45:36 2020 -0500 c++: Unshare expressions from constexpr cache. Another place we need to unshare cached expressions. PR c++/92852 - ICE with generic lambda and reference var. * constexpr.c (maybe_constant_value): Likewise.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jason Merrill --- Fixed for 8.4/9.3/10.
[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93377 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/93425] Template parameter deduction failure when template parameters have template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425 --- Comment #1 from andysem at mail dot ru --- Also, the compilation succeeds if I explicitly specify the NumberT template parameter at the call site.
[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #5 from Jeffrey A. Law --- Given this mess is my code, I'll take it.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
--- Comment #5 from kloetzl ---
Sorry for missing out the details, here goes:
I work in a Debian Hurd 20290705 image using qemu. The example file is given
above. Compiling with `gcc -Wall -Wextra ifunc.c` produces the following error.
error: ifunc is not supported on this target
int fn(void) __attribute((ifunc("fn_select")));
The output of gcc -v is (may contain typos)
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-gnu/8/lto-wrapper
Target: i686-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-7'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --program-prefix=i686-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-include-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --disable-libitm --disable-libsanitizer
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos
--enable-multiarch --disable-werror --with-arch=i586 --with-tune=generic
--enable-checking=release --build=i686-gnu --host-i686-gnu --target=i686-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-7)
So it is not 9.0 as I first thought.
Hope this helps.
[Bug c++/93400] [10 Regression] ICE: in tsubst, at cp/pt.c:15142 on friends with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93400 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-24 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788 --- Comment #6 from Jeffrey A. Law --- We shouldn't have threaded this to begin with. I think I see what went wrong here.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #15 from Iain Sandoe --- (In reply to David Edelsohn from comment #14) > Compiler version: 10.0.1 20200124 (experimental) [src revision > 96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) > > You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html Likewise on powerpc-darwin9 (32b host, PIC by default) I see the setjmp case r10-6194 (but I will retest with all your changes in place).
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
--- Comment #6 from Marek Polacek ---
This passes dg.exp but I haven't convinced it's the right solution so haven't
posted it...
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21849,8 +21849,12 @@ type_unification_real (tree tparms,
NULL_TREE);
if (!uses_template_parms (substed))
- arg = convert_template_argument (parm, substed, full_targs,
-complain, i, NULL_TREE);
+ {
+ ++processing_template_decl;
+ arg = convert_template_argument (parm, substed, full_targs,
+ complain, i, NULL_TREE);
+ --processing_template_decl;
+ }
else if (saw_undeduced == 1)
arg = NULL_TREE;
else
[Bug lto/93166] [10 Regression] ICE in get_info_about_necessary_edges, at ipa-cp.c:4137 since r278893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93166 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #6 from Jeffrey A. Law --- I've got state, so I'll take this as well.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #16 from Iain Sandoe --- (In reply to Iain Sandoe from comment #15) > (In reply to David Edelsohn from comment #14) > > Compiler version: 10.0.1 20200124 (experimental) [src revision > > 96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) > > > > You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html > > Likewise on powerpc-darwin9 (32b host, PIC by default) I see the setjmp > case r10-6194 (but I will retest with all your changes in place). Oops, that was somewhat incoherent. https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01190.html in addition to the cases mentioned above (and which I will open new PRs for after re-running with all your current changes). on powerpc-darwin9 only, I still see the setjmp fails that David (E) is seeing on AIX.
[Bug c++/93299] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299 Marek Polacek changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |tsubst_copy, at |tsubst_copy, at |cp/pt.c:15779 |cp/pt.c:15779 --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/93299] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d54a86cd92860e1108f43fae9329ccb0897f3e1d commit r10-6212-gd54a86cd92860e1108f43fae9329ccb0897f3e1d Author: Marek Polacek Date: Fri Jan 17 15:17:42 2020 -0500 c++: Fix ICE in tsubst_copy with parenthesized expression [PR93299] Since e4511ca2e9ecdb51d41b64452398f8e2df575668 force_paren_expr can create a VIEW_CONVERT_EXPR so that we have something to set REF_PARENTHESIZED_P on, while not making the expression dependent. But tsubst_copy can't cope with such a VIEW_CONVERT_EXPR, because it's not location_wrapper_p, or a TEMPLATE_PARM_INDEX wrapped in a VIEW_CONVERT_EXPR. I think we need to teach tsubst_copy how to handle it. Setting EXPR_LOCATION_WRAPPER_P in force_paren_expr would make the ICE go away too, but tsubst_copy would lose the REF_PARENTHESIZED_P flag. 2020-01-24 Marek Polacek PR c++/93299 - ICE in tsubst_copy with parenthesized expression. * pt.c (tsubst_copy): Handle a REF_PARENTHESIZED_P VIEW_CONVERT_EXPR. * g++.dg/cpp1y/paren5.C: New test.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #3 from Devin Hussey --- I think I found the culprit commit. Haven't set up a GCC build tree yet, though. https://github.com/gcc-mirror/gcc/commit/a51c4926712307787d133ba50af8c61393a9229b
[Bug fortran/93422] Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422 --- Comment #1 from Andrew Benson --- Using a "result()" for the return value of the function allows this to compile successfully: module t type :: a contains procedure :: p => ap end type a type, extends(a) :: b contains procedure :: p => bp end type b type :: c end type c type, extends(c) :: d end type d interface module function bp(s) result(ss) class(b), intent(inout) :: s class(d), pointer :: ss end function end interface contains function ap(s) result(ss) class(d), pointer :: ss class(a), intent(inout) :: s end function ap end module t submodule (t) ts contains function bp(s) result(ss) class(d), pointer :: ss class(b), intent(inout) :: s end function bp end submodule ts
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #20 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6ccc19bd4d12379a0d9fce486ceba3207749424a commit r10-6213-g6ccc19bd4d12379a0d9fce486ceba3207749424a Author: Andrew Pinski Date: Sat Jan 11 20:34:24 2020 + Decrease cortexa57_extra_costs's alu.shift_reg Like I mentioned in https://gcc.gnu.org/ml/gcc/2020-01/msg00157.html, The shift by a register should be just COSTS_N_INSNS (1) rather than COSTS_N_INSNS (2). This allows lshift_cheap_p to return true now and converting switches to be using shift and other like structures. I noticed this difference when I was working through PR 93131 and understanding what reassoc could handle. ChangeLog: * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): Change alu.shift_reg to 0.
[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #8 from Andrew Pinski --- (In reply to Tamar Christina from comment #7) > In file included from > /data/tamchr01/write-access/gcc-git/libgcc/unwind-dw2.c:403:0: > ./md-unwind-support.h: In function 'x86_64_fallback_frame_state': > ./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type > 'struct ucontext' >sc = (struct sigcontext *) (void *) &uc_->uc_mcontext; > > and disabling libgcc doesn't get me very far because of the dependencies of > things on it. You must be using a too new glibc, g:883312dc79806f513275b72502231c751c14ff72 is what fixed libgcc to support newer glibc.
[Bug c/93410] [9 only] can't use _Decimal64 in C99/C11/C17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410 --- Comment #2 from joseph at codesourcery dot com --- On Fri, 24 Jan 2020, pinskia at gcc dot gnu.org wrote: > I doubt GCC 9 is going to change. Indeed. The old approach was inconsistent with normal practice, as I said in commit fe2bc27cdb6d572da0163d77e787ba644b400753 (r276896, "Support _Decimal* keywords for C2x."): The _Decimal* keywords are marked with D_EXT, meaning they are not considered keywords at all in strict conformance modes. This is contrary to the normal practice for most implementation-namespace keywords, which are accepted in all standards modes but with appropriate pedwarns for older standards. This patch removes D_EXT from those keywords so they are accepted as keywords for all standards, consequently removing the gcc.dg/dfp/keywords-ignored-c99.c test that is no longer valid. But that's not the sort of change we make on past release branches.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- (In reply to Devin Hussey from comment #3) > I think I found the culprit commit. > > Haven't set up a GCC build tree yet, though. > > https://github.com/gcc-mirror/gcc/commit/ > a51c4926712307787d133ba50af8c61393a9229b g:6a03477e85e1b097ed6c0b86c76436de575aef04 for the new git.
[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93376 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14e5881e37771f1f58123e77c558adb3b90c8764 commit r10-6214-g14e5881e37771f1f58123e77c558adb3b90c8764 Author: Jakub Jelinek Date: Fri Jan 24 22:47:23 2020 +0100 simplify-rtx: Punt for modes with precision above MAX_BITSIZE_MODE_ANY_INT [PR93376] The following patch makes sure we punt in the 3 spots if precision is above MAX_BITSIZE_MODE_ANY_INT. 2020-01-24 Jakub Jelinek PR target/93376 * simplify-rtx.c (simplify_const_unary_operation, simplify_const_binary_operation): Punt for mode precision above MAX_BITSIZE_MODE_ANY_INT.
[Bug c++/93406] No argument checking for wchar_t variants of print-like functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93406 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Joseph S. Myers --- As a duplicate, if you have questions they should be raised in the main bug report; don't reopen a duplicate one unless you have an argument for it not being a duplicate. The question is how best to *cleanly* support format checking for wide string formats, when narrow format strings can be tricky mixtures of bytes and multibyte characters. I think the answer involves implementing some general set of accessors (not accessors restricted to the case of format checking) for accessing bytes / multibyte characters / wide characters in string constants (nowadays, that would probably be a fairly simple C++ class abstracting access to target strings in some way). Such accessors could then incrementally be used elsewhere in the compiler when elements of strings need to be accessed. *** This bug has been marked as a duplicate of bug 38308 ***
[Bug target/93395] AVX2 missed optimization : _mm256_permute_pd() is unfortunately translated into the more expensive VPERMPD instead of the cheap VPERMILPD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93395 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5d782a8d909c5cc472c911c0ab4de0b890aad868 commit r10-6215-g5d782a8d909c5cc472c911c0ab4de0b890aad868 Author: Jakub Jelinek Date: Fri Jan 24 22:49:51 2020 +0100 i386: prefer vpermilpd over vpermpd [PR93395] In Agner Fog's tables, vpermilp[sd] with immediates seem to be much faster than vpermpd with immediate, for a good reason, the former only permute something within the lanes and don't do anything intra-lane, while vpermpd can. So, functionality-wise, vpermilpd is more efficient subset of vpermpd. We use the same RTL for those though (and also for certain broadcast). Now, the problem was that the vpermpd pattern appeared first in sse.md, followed by the broadcast patterns, followed by the vpermilp[sd]. Which means unless -mavx -mno-avx2, we'd emit vpermpd instead of the more efficient alternatives. The following patch reorders them, so that vpermpd comes last, if we can match a broadcast, we do, if we can match a vpermilp[sd] that is not a broadcast, we will, otherwise fall back (of course only if -mavx2) to vpermpd. 2020-01-24 Jakub Jelinek PR target/93395 * config/i386/sse.md (*avx_vperm_broadcast_v4sf, *avx_vperm_broadcast_, _vpermil, *_vpermilp): Move before avx2_perm/avx512f_perm. * gcc.target/i386/pr93395.c: New test. * gcc.target/i386/avx512vl-vpermilpdi-1.c: Remove xfail.
[Bug c/38308] -Wformat does not work for wide strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38308 --- Comment #6 from Joseph S. Myers --- *** Bug 93406 has been marked as a duplicate of this bug. ***
[Bug analyzer/93276] Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93276 --- Comment #2 from David Malcolm --- Created attachment 47705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47705&action=edit Patch that fixes the build with gcc 4.4
[Bug target/93395] AVX2 missed optimization : _mm256_permute_pd() is unfortunately translated into the more expensive VPERMPD instead of the cheap VPERMILPD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93395 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 10+.
[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93376 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug c++/93413] Destructor definition not found during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-24 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Seems to be dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695#c12 I'm afraid I don't know how to resolve this.
[Bug target/93412] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_add_overflow() at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93412 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-24 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I'll have a look.
[Bug tree-optimization/93411] variable reference to constant array with same elements not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93411 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Looks like https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01559.html , but Richi didn't like that. Would need to dig up IRC log what were the issues; that said, nothing has been done about it since then.
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Sergei Trofimovich --- In https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01682.html Jakub pointed out that was a fixable glibc bug. I assume it was fixed in https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=768c83b7f60d82db6677e19dc51be9f341e0f3fc closing this bug as INVALID. Apologies for the noise.
[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93377 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:55dd44535d2e4e5703c0103c26e7c51ab8c502c4 commit r10-6216-g55dd44535d2e4e5703c0103c26e7c51ab8c502c4 Author: Jason Merrill Date: Thu Jan 23 16:59:54 2020 -0500 c++: Fix parameter map handling of member typedef. any_template_parm_r was looking at the args of an alias template-id, but we need to look at all args of a member alias/typedef, including implicit ones from the enclosing class. PR c++/93377 - ICE with member alias in constraint. * pt.c (any_template_parm_r): Look at template arguments for all aliases, not only alias templates.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #18 from Janne Blomqvist --- Assigning to myself, looking into the locking errors.
