[Bug c/82100] gcc does not warn about code that is unreachable due to conflicting conditions [subset of reviving -Wunreachable-code]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82100 --- Comment #5 from David Binderman --- clang 11.0.0-rc2 also can't find problems in the two above code fragments. This code problem doesn't occur in gcc source code, but there are about a dozen cases in the linux kernel.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #2 from Eric Botcazou ---
The statement generated by DSE
MEM [(struct Data *)&data + 8B] = {};
looks nonsensical and I guess store-merging is not prepared for it.
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:972da557463ec946a31577294764a186b9821012 commit r11-3200-g972da557463ec946a31577294764a186b9821012 Author: Tobias Burnus Date: Tue Sep 15 09:24:47 2020 +0200 OpenMP/Fortran: Fix (re)mapping of allocatable/pointer arrays [PR96668] gcc/cp/ChangeLog: PR fortran/96668 * cp-gimplify.c (cxx_omp_finish_clause): Add bool openacc arg. * cp-tree.h (cxx_omp_finish_clause): Likewise * semantics.c (handle_omp_for_class_iterator): Update call. gcc/fortran/ChangeLog: PR fortran/96668 * trans.h (gfc_omp_finish_clause): Add bool openacc arg. * trans-openmp.c (gfc_omp_finish_clause): Ditto. Use GOMP_MAP_ALWAYS_POINTER with PSET for pointers. (gfc_trans_omp_clauses): Like the latter and also if the always modifier is used. gcc/ChangeLog: PR fortran/96668 * gimplify.c (gimplify_omp_for): Add 'bool openacc' argument; update omp_finish_clause calls. (gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses, gimplify_expr, gimplify_omp_loop): Update omp_finish_clause and/or gimplify_for calls. * langhooks-def.h (lhd_omp_finish_clause): Add bool openacc arg. * langhooks.c (lhd_omp_finish_clause): Likewise. * langhooks.h (lhd_omp_finish_clause): Likewise. * omp-low.c (scan_sharing_clauses): Keep GOMP_MAP_TO_PSET cause for 'declare target' vars. include/ChangeLog: PR fortran/96668 * gomp-constants.h (GOMP_MAP_ALWAYS_POINTER_P): Define. libgomp/ChangeLog: PR fortran/96668 * libgomp.h (struct target_var_desc): Add has_null_ptr_assoc member. * target.c (gomp_map_vars_existing): Add always_to_flag flag. (gomp_map_vars_existing): Update call to it. (gomp_map_fields_existing): Likewise (gomp_map_vars_internal): Update PSET handling such that if a nullptr is now allocated or if GOMP_MAP_POINTER is used PSET is updated and pointer remapped. (GOMP_target_enter_exit_data): Hanlde GOMP_MAP_ALWAYS_POINTER like GOMP_MAP_POINTER. * testsuite/libgomp.fortran/map-alloc-ptr-1.f90: New test. * testsuite/libgomp.fortran/map-alloc-ptr-2.f90: New test.
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 --- Comment #6 from Tobias Burnus --- Fixed for pointer/allocatable arrays. Still to be done: scalar pointers/allocatable; here, one needs to be careful as pointer/always pointer is already used for, e.g., struct mapping – and always pointer currently assumes that the pointer is already present (assert; change?). Plus: ensure the refcounting works correctly.
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0f079e104a8d1994b6b47169a6b45737615eb2d7
commit r11-3201-g0f079e104a8d1994b6b47169a6b45737615eb2d7
Author: Jakub Jelinek
Date: Tue Sep 15 09:37:48 2020 +0200
i386: Fix up vector mul and div with broadcasts in -masm=intel mode
These patterns printed bogus <>s around the {1to16} and similar strings.
2020-09-15 Jakub Jelinek
PR target/97028
* config/i386/sse.md (mul3_bcs,
_div3_bcst): Use instead of
<>.
* gcc.target/i386/avx512f-pr97028.c: Untested fix.
[Bug target/97056] New: [11 regression] aarch64/sve/cost_model_2.c fails on aarch64_be since r11-3148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97056 Bug ID: 97056 Summary: [11 regression] aarch64/sve/cost_model_2.c fails on aarch64_be since r11-3148 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r11-3148 (g:8d3767c30240c901a493d82d9d20f306b2f0152d), I've noticed that: FAIL: gcc.target/aarch64/sve/cost_model_2.c -march=armv8.2-a+sve scan-assembler-times \\tstr\\tq 1 gcc.target/aarch64/sve/cost_model_2.c -march=armv8.2-a+sve : \\tstr\\tq found 0 times
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053 --- Comment #3 from Jakub Jelinek --- Started with my r10-179-g3afd514bca6ea572e614b5289c4429ace693311b I'll have a look.
[Bug debug/96690] [10 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||10.2.1 Known to fail||10.2.0 --- Comment #10 from Richard Biener --- Fixed.
[Bug debug/96690] [10 Regression] ICE in write_type since r10-6087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:bfe7bfbd068ee752f9d264473f974883ec6a21e6 commit r10-8764-gbfe7bfbd068ee752f9d264473f974883ec6a21e6 Author: Richard Biener Date: Mon Aug 24 14:12:01 2020 +0200 debug/96690 - mangle symbols eventually used by late dwarf output The following makes sure to, at early debug generation time, mangle symbols we eventually end up outputting during late finish. 2020-08-24 Richard Biener PR debug/96690 * dwarf2out.c (reference_to_unused): Make FUNCTION_DECL processing more consistent with respect to symtab->global_info_ready. (tree_add_const_value_attribute): Unconditionally call rtl_for_decl_init to do all mangling early but throw away the result if early_dwarf. * g++.dg/lto/pr96690_0.C: New testcase. (cherry picked from commit 7fe2cec41bb2ccb499b6b6c513e00da1a270370f)
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d0a094ce39fc49681b0d5cfd2ee1d232859c4824
commit r9-8871-gd0a094ce39fc49681b0d5cfd2ee1d232859c4824
Author: Jakub Jelinek
Date: Tue Sep 15 09:37:48 2020 +0200
i386: Fix up vector mul and div with broadcasts in -masm=intel mode
These patterns printed bogus <>s around the {1to16} and similar strings.
2020-09-15 Jakub Jelinek
PR target/97028
* config/i386/sse.md (mul3_bcs,
_div3_bcst): Use instead of
<>.
* gcc.target/i386/avx512f-pr97028.c: Untested fix.
(cherry picked from commit 0f079e104a8d1994b6b47169a6b45737615eb2d7)
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:55cd12c65ffa1e7c0bb36fd398f178d5d15d660f
commit r10-8765-g55cd12c65ffa1e7c0bb36fd398f178d5d15d660f
Author: Jakub Jelinek
Date: Tue Sep 15 09:37:48 2020 +0200
i386: Fix up vector mul and div with broadcasts in -masm=intel mode
These patterns printed bogus <>s around the {1to16} and similar strings.
2020-09-15 Jakub Jelinek
PR target/97028
* config/i386/sse.md (mul3_bcs,
_div3_bcst): Use instead of
<>.
* gcc.target/i386/avx512f-pr97028.c: Untested fix.
(cherry picked from commit 0f079e104a8d1994b6b47169a6b45737615eb2d7)
[Bug target/97028] [9/10/11 Regression] Compilation errors for AVX512 intrinsic with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 9.4/10.3/11.1+.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
struct S { short a; char b[9]; int c; char d; int e; };
__attribute__((noipa)) void
foo (char *x, char *y)
{
if (__builtin_strcmp (x, "ABCD") != 0
|| __builtin_strcmp (y, "ABCD") != 0)
__builtin_abort ();
}
int
main ()
{
char a[9] = "";
struct S b = {};
__builtin_memcpy (a, "ABCD", 4);
b.a = 5;
__builtin_memcpy (b.b, a, 8);
b.d = 'X';
b.e = 1;
foo (a, b.b);
return 0;
}
[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882 --- Comment #7 from emilie.feral at numworks dot com --- Hello, Any news on the subject? Would you advise in the meantime to discard the LTO (with the -fno-lto option) on the compilation unit containing the failing code? The bug occurred for us when returning a structure of four doubles. Do you have any indication of when the bug might appear to help us track other occurrences? Thanks for helping!
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #5 from Jakub Jelinek ---
Better testcase that won't cease to test the bug even if FRE or some other pass
gets smarter and optimizes the a = ""; __builtin_memcpy (&a, "ABCD",
4);
into a = "ABCD":
struct S { short a; char b[9]; int c; char d; int e; };
__attribute__((noipa)) void
foo (struct S *x)
{
if (__builtin_strcmp (x->b, "ABCD") != 0)
__builtin_abort ();
}
__attribute__((noipa)) void
bar (char *x)
{
struct S b = {};
b.a = 5;
__builtin_memcpy (b.b, x, 8);
b.d = 'X';
b.e = 1;
foo (&b);
}
int
main ()
{
bar ("ABCD");
return 0;
}
(In reply to Eric Botcazou from comment #2)
> The statement generated by DSE
>
> MEM [(struct Data *)&data + 8B] = {};
>
> looks nonsensical and I guess store-merging is not prepared for it.
There is nothing non-sensical nor wrong on it, it is standard GIMPLE IL,
equivalent in behavior to __builtin_memset (&data + 8B, 0, 12);
[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591 Tony E Lewis changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Tony E Lewis --- Closing as fixed.
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744 --- Comment #14 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:ecc3135a4a264b66c163ef32e815a99746b81800 commit r11-3202-gecc3135a4a264b66c163ef32e815a99746b81800 Author: liuhongt Date: Mon Aug 24 20:36:52 2020 +0800 Retune mask <->integer cost for non-AVX512 micro-architecture. gcc/ChangeLog: PR target/96744 * config/i386/x86-tune-costs.h (struct processor_costs): Increase mask <-> integer cost for non AVX512 target to avoid spill gpr to mask. Also retune mask <-> integer and mask_load/store for skylake_cost.
[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744 --- Comment #15 from Hongtao.liu --- Fixed in GCC11.
[Bug target/95646] arm-none-eabi function attribute 'cmse_nonsecure_entry' wipes register values with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646 --- Comment #3 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:80297f897758f59071968ddff2a04a8d11481117 commit r11-3203-g80297f897758f59071968ddff2a04a8d11481117 Author: Andre Vieira Date: Mon Sep 14 09:03:08 2020 +0100 arm: Fix testisms introduced with fix for pr target/95646 This patch changes the test to use the effective-target machinery disables the error message "ARMv8-M Security Extensions incompatible with selected FPU" when -mfloat-abi=soft. Further changes 'asm' to '__asm__' to avoid failures with '-std=' options. gcc/ChangeLog: 2020-07-06 Andre Vieira * config/arm/arm.c (arm_options_perform_arch_sanity_checks): Do not check +D32 for CMSE if -mfloat-abi=soft gcc/testsuite/ChangeLog: 2020-07-06 Andre Vieira * gcc.target/arm/pr95646.c: Fix testism.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053 --- Comment #6 from Jakub Jelinek --- I think the problem is that check_no_overlap only looks at later m_store_info stores that would overlap and cause problems. But in this case, the problem is that we'd need to check earlier m_store_info store too. We have in the stmt order bitpos bitsize kind order 64 96 INTEGER_CST 0 0 16 INTEGER_CST 1 16 64 MEM_REF 2 128 8 INTEGER_CST 3 160 32 INTEGER_CST 4 After sort_by_bitpos this is: 0 16 INTEGER_CST 1 16 64 MEM_REF 2 64 96 INTEGER_CST 0 128 8 INTEGER_CST 3 160 32 INTEGER_CST 4 The first store in this order doesn't overlap anything and is followed by adjacent store of incompatible kind, so is kept as is. Then the MEM_REF store is kept as is too, because again it overlaps with the next one, but is of a different kind. The bug is when deciding if the 3rd store could be mergeable with the 4th store. They are overlapping and of the same kind that can be handled for overlapping stores, but they shouldn't be merged, because there was a non-mergeable overlapping store in between them in the sort_by_order order (the MEM_REF one).
[Bug target/96201] x86 movsd/movsq string instructions and alignment inference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96201 bin cheng changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #2 from bin cheng --- Reason is that memory references in f3 are not identified as address type IV uses. I don't remember details, but it's intended by below commit: commit 653a4b32fe72e33bfd4cdd4c25493049524a3805 Author: Bin Cheng Date: Thu Mar 2 11:25:11 2017 + re PR tree-optimization/66768 (address space gets lost on literal pointer) PR tree-optimization/66768 * tree-ssa-loop-ivopts.c (find_interesting_uses_address): Skip addr iv_use if base object can't be determined. gcc/testsuite * gcc.target/i386/pr66768.c: New test. From-SVN: r245837 For f1/f2, IVOPTs fails to identify base object because pointers are converted from integer. We need to tell the difference better. For f3, __builtin_assume_aligned is optimized away by GCC-10 before IVOPTs.
[Bug middle-end/97054] [10/11 Regression] Runtime segfault with attached test code since r10-3559
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97054 --- Comment #1 from H.J. Lu --- Created attachment 49220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49220&action=edit A patch I am testing this.
[Bug target/97056] [11 regression] aarch64/sve/cost_model_2.c fails on aarch64_be since r11-3148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97056 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |11.0 Version|10.0|11.0 --- Comment #1 from Richard Biener --- Did it pass at g:484af18ee1c63eb8d212563e40aa765da5be7f82 thus before the g:47ddf4c7b1d4471cb9534f27844ab5e4279c2168 change?
[Bug target/97056] [11 regression] aarch64/sve/cost_model_2.c fails on aarch64_be since r11-3148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97056 --- Comment #2 from Christophe Lyon --- No, it was failing at that time. It started passing between r11-3093 and r11-3103, and fails again since r11-3148.
[Bug target/97056] [11 regression] aarch64/sve/cost_model_2.c fails on aarch64_be since r11-3148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97056 --- Comment #3 from Richard Biener --- OK, in between the revs the cost modeling was disabled so that would explain it, we just got back to the previous state then.
[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #24 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:bab581381681813ab3ccd007195777c1f816e656 commit r11-3205-gbab581381681813ab3ccd007195777c1f816e656 Author: Segher Boessenkool Date: Mon Sep 14 18:19:47 2020 + bb-reorder: Fix for ICEs caused by 69ca5f3a9882 After the previous patch we are left with an unreachable BB. This will ICE if either we have -fschedule-fusion, or we do not have peephole2. 2020-09-15 Segher Boessenkool PR rtl-optimization/96475 * bb-reorder.c (duplicate_computed_gotos): If we did anything, run cleanup_cfg.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #7 from Jakub Jelinek ---
Another testcase for -O2 -fno-tree-dse that shows more issues, that it affects
not just the overlapping case handling, but also can affect also the adjacent
cases:
struct __attribute__((packed, may_alias)) S { long long s; };
struct __attribute__((packed, may_alias)) T { short t; };
__attribute__((noipa)) void
test (char *p, char *q, int s)
{
if ((s & 1) == 0)
{
if (*(short __attribute__((may_alias)) *) &p[sizeof (short)]
!= *(short __attribute__((may_alias)) *) &q[sizeof (short)]
|| (((struct S __attribute__((may_alias)) *) &p[1])->s
!= ((struct S __attribute__((may_alias)) *) &q[1])->s)
|| (*(short __attribute__((may_alias)) *) &p[2 * sizeof (short)]
!= *(short __attribute__((may_alias)) *) &q[2 * sizeof (short)]))
__builtin_abort ();
}
else
{
if (*(short __attribute__((may_alias)) *) &p[sizeof (short)]
!= *(short __attribute__((may_alias)) *) &q[sizeof (short)]
|| (((struct S __attribute__((may_alias)) *) &p[1])->s
!= ((struct S __attribute__((may_alias)) *) &q[1])->s)
|| (((struct T __attribute__((may_alias)) *) &p[2 * sizeof (short) -
1])->t
!= ((struct T __attribute__((may_alias)) *) &q[2 * sizeof (short)
- 1])->t)
|| p[3 * sizeof (short) - 2] != q[3 * sizeof (short) - 2])
__builtin_abort ();
}
}
__attribute__((noipa)) void
foo (long long *p, char *q, char *r, char *s)
{
char a[64] __attribute__((aligned (__alignof (short;
*(short __attribute__((may_alias)) *) &a[sizeof (short)] = 1;
((struct S __attribute__((may_alias)) *) &a[1])->s = p[0];
*(short __attribute__((may_alias)) *) &a[2 * sizeof (short)] = 2;
*(short __attribute__((may_alias)) *) &q[sizeof (short)] = 1;
((struct S __attribute__((may_alias)) *) &r[1])->s = p[0];
*(short __attribute__((may_alias)) *) &s[2 * sizeof (short)] = 2;
test (a, q, 0);
}
__attribute__((noipa)) void
bar (long long *p, char *q, char *r, char *s, char *t)
{
char a[64] __attribute__((aligned (__alignof (short;
*(short __attribute__((may_alias)) *) &a[sizeof (short)] = 1;
((struct S __attribute__((may_alias)) *) &a[1])->s = p[0];
((struct T __attribute__((may_alias)) *) &a[2 * sizeof (short) - 1])->t = 2;
a[3 * sizeof (short) - 2] = 3;
*(short __attribute__((may_alias)) *) &q[sizeof (short)] = 1;
((struct S __attribute__((may_alias)) *) &r[1])->s = p[0];
((struct T __attribute__((may_alias)) *) &s[2 * sizeof (short) - 1])->t = 2;
t[3 * sizeof (short) - 2] = 3;
test (a, q, 1);
}
__attribute__((noipa)) void
baz (long long *p, char *q, char *r, char *s)
{
char a[64] __attribute__((aligned (__alignof (short;
*(short __attribute__((may_alias)) *) &a[2 * sizeof (short)] = 2;
((struct S __attribute__((may_alias)) *) &a[1])->s = p[0];
*(short __attribute__((may_alias)) *) &a[sizeof (short)] = 1;
*(short __attribute__((may_alias)) *) &q[2 * sizeof (short)] = 2;
((struct S __attribute__((may_alias)) *) &r[1])->s = p[0];
*(short __attribute__((may_alias)) *) &s[sizeof (short)] = 1;
test (a, q, 2);
}
__attribute__((noipa)) void
qux (long long *p, char *q, char *r, char *s, char *t)
{
char a[64] __attribute__((aligned (__alignof (short;
*(short __attribute__((may_alias)) *) &a[2 * sizeof (short) - 1] = 2;
((struct S __attribute__((may_alias)) *) &a[1])->s = p[0];
a[3 * sizeof (short) - 2] = 3;
*(short __attribute__((may_alias)) *) &a[sizeof (short)] = 1;
((struct T __attribute__((may_alias)) *) &q[2 * sizeof (short) - 1])->t = 2;
((struct S __attribute__((may_alias)) *) &r[1])->s = p[0];
s[3 * sizeof (short) - 2] = 3;
((struct T __attribute__((may_alias)) *) &t[sizeof (short)])->t = 1;
test (a, q, 3);
}
int
main ()
{
char a[64];
long long p = -1LL;
foo (&p, &a[0], &a[0], &a[0]);
bar (&p, &a[0], &a[0], &a[0], &a[0]);
baz (&p, &a[0], &a[0], &a[0]);
qux (&p, &a[0], &a[0], &a[0], &a[0]);
return 0;
}
[Bug middle-end/97054] [10/11 Regression] Runtime segfault with attached test code since r10-3559
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97054 H.J. Lu changed: What|Removed |Added CC||vmakarov at redhat dot com Keywords||patch --- Comment #2 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553968.html
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2020-09-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #10 from Segher Boessenkool --- (In reply to Alan Modra from comment #9) > I think that splitter should disappear and rs6000_emit_set_long_const handle > all special cases where you might want combinations of two logical > instructions before handling the li;rldicl, li;rldicr or any other > expansions with rotates. Yeah, that would be much easier to read and maintain. Good plan.
[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #8 from Richard Earnshaw ---
(In reply to emilie.feral from comment #7)
> Hello,
> Any news on the subject?
> Would you advise in the meantime to discard the LTO (with the -fno-lto
> option) on the compilation unit containing the failing code?
> The bug occurred for us when returning a structure of four doubles. Do you
> have any indication of when the bug might appear to help us track other
> occurrences?
> Thanks for helping!
Sorry, I haven't had time to work on this yet.
The safest work-around for now is to add an additional attribute to force the
PCS to the default for the selected ABI - I think adding
pcs("aapcs-vfp")
to the attributes will solve the problem.
ie.
AtLeast32BytesObject __attribute__((noinline, pcs("aapcs-vfp")))
CalledFunction() {
AtLeast32BytesObject result = {1.1, 2.2, 3.3, 4.4};
return result;
}
[Bug tree-optimization/94234] missed ccp folding for (addr + 8 * n) - (addr + 8 * (n - 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94234 --- Comment #5 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:8f0d743c2dee6afae5c6f861b0642b7b112a4a70 commit r11-3207-g8f0d743c2dee6afae5c6f861b0642b7b112a4a70 Author: Feng Xue Date: Mon Aug 17 23:00:35 2020 +0800 tree-optimization/94234 - add plusminus-with-convert pattern Add a rule (T)(A) +- (T)(B) -> (T)(A +- B), which works only when (A +- B) could be folded to a simple value. By this rule, a plusminus-mult-with-convert expression could be handed over to the rule (A * C) +- (B * C) -> (A +- B). 2020-09-15 Feng Xue gcc/ PR tree-optimization/94234 * match.pd (T)(A) +- (T)(B) -> (T)(A +- B): New simplification. gcc/testsuite/ PR tree-optimization/94234 * gcc.dg/pr94234-3.c: New test.
[Bug tree-optimization/97053] [10/11 Regression] an O2, O3 codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Jakub Jelinek --- Created attachment 49221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49221&action=edit gcc11-pr97053.patch Untested fix.
[Bug libstdc++/97057] New: [11 regression] Error in build gcc after r11-3149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057
Bug ID: 97057
Summary: [11 regression] Error in build gcc after r11-3149
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:b32d2ea8c29203519fbd9c5e90b06941e7cd75f3, r11-3149
On one of our servers the system gcc (4.8.5) can't build trunk any more. Note
that this is the same gcc version as on some of the gcc powerpc64 farm
machines.
/home/seurer/gcc/git/build/gcc-trunk/./gcc/xgcc -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-trunk/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-trunk/powerpc64le-unknown-linux-gnu/sys-include
-x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE
-I/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc64le-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/regex:58,
from
/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/include/precompiled/stdc++.h:110:
/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/regex_error.h:171:54:
error: expected ',' or '...' before '(' token
171 | const char* __what__attribute__((unused)))
| ^
In file included from
/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cassert:43,
from
/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/include/precompiled/stdc++.h:33:
/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/regex_error.h:
In function 'void std::__throw_regex_error(std::regex_constants::error_type,
const char*)':
/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/regex_error.h:172:5:
error: '__what' was not declared in this scope
172 | { _GLIBCXX_THROW_OR_ABORT(regex_error(__ecode, __what)); }
| ^~~
seurer@tulibee:~/gcc/git/build/gcc-trunk$ gcc -v
...
gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)
commit b32d2ea8c29203519fbd9c5e90b06941e7cd75f3
Author: Christophe Lyon
Date: Fri Sep 11 11:53:15 2020 +
libstdc++-v3/include/bits/regex_error.h: Avoid warning with
-fno-exceptions.
When building with -fno-exceptions, __GLIBCXX_THROW_OR_ABORT expands to
abort(), causing warnings:
unused parameter '__ecode'
unused parameter '__what'
This patch adds __attribute__((unused)) to avoid them.
2020-09-11 Torbjrn SVENSSON
Christophe Lyon
libstdc++-v3/
* include/bits/regex_error.h: Avoid warning with -fno-exceptions.
[Bug libstdc++/97057] [11 regression] Error in build gcc after r11-3149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Christophe Lyon --- This typo was fixed a few commits later: r11-3159 g:29216f56d002982f10c33056f4b3d7f07e164122
[Bug libstdc++/97057] [11 regression] Error in build gcc after r11-3149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057 --- Comment #2 from seurer at gcc dot gnu.org --- Sorry. I am still seeing a compilation error and bisect erroneously traced it here.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 96987, which changed state. Bug 96987 Summary: [11 regression] warning 'ptr' may be used uninitialized const pointer parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Martin Sebor --- The warning is by design and based on the assumption that a function declared to take a const pointer (or in C++, a const reference) as an argument reads the pointed-to-object. If that's not the case annotating the function declaration with attribute as shgwn below suppresses the warning: extern __attribute__ ((access (none, 1))) void constparam(const int *ptr);
[Bug target/96139] Vector element extract mistypes long long int down to long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Will Schmidt : https://gcc.gnu.org/g:ba0bc8fa005921832c4665e5b5a18932d3f4ccf4 commit r10-8766-gba0bc8fa005921832c4665e5b5a18932d3f4ccf4 Author: Will Schmidt Date: Mon Jul 20 10:51:37 2020 -0500 [PATCH, rs6000] Fix vector long long subtype (PR96139) Hi, This corrects an issue with the powerpc vector long long subtypes. As reported by SjMunroe, when building some code with -Wall, and attempting to print an element of a "long long vector" with a long long printf format string, we will report an error because the vector sub-type was improperly defined as int. When defining a V2DI_type_node we use a TARGET_POWERPC64 ternary to define the V2DI_type_node with "vector long" or "vector long long". We also need to specify the proper sub-type when we define the type. PR target/96139 2020-09-03 Will Schmidt gcc/ChangeLog: * config/rs6000/rs6000-call.c (rs6000_init_builtin): Update V2DI_type_node and unsigned_V2DI_type_node definitions. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr96139-a.c: New test. * gcc.target/powerpc/pr96139-b.c: New test. * gcc.target/powerpc/pr96139-c.c: New test. (cherry picked from commit d8f3474ff81b07fd2e758337957711db17eb801e)
[Bug driver/97058] New: invalid "cc1: warning: '-Werror=' argument '-funroll-completely-grow-size' is not valid for C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97058 Bug ID: 97058 Summary: invalid "cc1: warning: '-Werror=' argument '-funroll-completely-grow-size' is not valid for C" Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Compiler output: $ echo '' > tst.c $ gcc -Wno-multichar -funroll-completely-grow-size -c tst.c cc1: warning: '-Werror=' argument '-funroll-completely-grow-size' is not valid for C $ gcc -Wno-multichar -funroll-completely-grow-size -xc++ -c tst.c cc1plus: warning: '-Werror=' argument '-funroll-completely-grow-size' is not valid for C++ $ gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-3201-20200915093938-g0f079e104a8-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-3201-20200915093938-g0f079e104a8-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200915 (experimental) (GCC)
[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96295 Martin Sebor changed: What|Removed |Added Known to fail||11.0 Keywords||patch Known to work||10.2.0 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553996.html
[Bug middle-end/97023] missing warning on buffer overflow in chained mempcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97023 Martin Sebor changed: What|Removed |Added Keywords||patch Target Milestone|--- |11.0 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:1b9bdd52037061d7a5bd77d177b060c93c528a5d commit r11-3211-g1b9bdd52037061d7a5bd77d177b060c93c528a5d Author: Tobias Burnus Date: Tue Sep 15 21:28:40 2020 +0200 libgomp/target.c: Silence -Wuninitialized warning libgomp/ChangeLog: PR fortran/96668 * target.c (gomp_map_vars_internal): Initialize has_nullptr.
[Bug libstdc++/97057] [11 regression] Error in build gcc after r11-3149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057 --- Comment #3 from Peter Bergner --- (In reply to seurer from comment #2) > Sorry. I am still seeing a compilation error and bisect erroneously traced > it here. FYI, the actual bootstrap issue was due to one of Mike's recent patches. Alex debugged the issue and posted a patch he will commit if it passes bootstrap: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553991.html
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 --- Comment #4 from Thomas Rodgers --- (In reply to andysem from comment #2) > Another use case is C++20 atomic_ref, which may be bound to an object whose > padding bits are in indeterminate state. An intrinsic to clear padding bits > without altering the object value could be useful. Having now implemented atomic::wait for libstdc++, I think the intrinsic to clear padding bits before calling __builtin_memcmp for generic (trivially copyable) T's is the right approach.
[Bug fortran/97036] [F2018] ELEMENTAL RECURSIVE subprogram prefix combination rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97036 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-09-15 Keywords||rejects-valid Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-September/055088.html
[Bug target/85198] long long int vector mistaken as long int vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198 Will Schmidt changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||willschm at gcc dot gnu.org --- Comment #6 from Will Schmidt --- This is a duplicate of PR96139. *** This bug has been marked as a duplicate of bug 96139 ***
[Bug target/96139] Vector element extract mistypes long long int down to long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 Will Schmidt changed: What|Removed |Added CC||kelvin at gcc dot gnu.org --- Comment #8 from Will Schmidt --- *** Bug 85198 has been marked as a duplicate of this bug. ***
[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96987 --- Comment #3 from Iain Buclaw --- And what about other front-ends that do not have the luxury of C attributes? Looking at the original library code of where the warning was noticed, the function being called (GC.addRange) definitely doesn't read the pointer, but records the address and allocation size for scanning later.
[Bug c++/97059] New: C++20: compound requirement uses inconsistent return type (adds ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97059
Bug ID: 97059
Summary: C++20: compound requirement uses inconsistent return
type (adds ref)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
The following code:
#include
template
struct s { constexpr static auto const n = N; };
template
concept S = requires (T t)
{
{ t.n } -> std::same_as ;
requires std::is_same_v ;
};
decltype (auto) f (S s) { return s.n; };
static_assert (std::is_same_v {})), std::size_t>);
static_assert (S >);
when compiled as:
g++ -std=c++20 -fconcepts-ts -fconcepts-diagnostics-depth=25 -Wall -Wextra -W
-O3 -o bug-4.o -c bug-4.cpp
breaks (messages below).
Compilation succeeds when NOBUG is defined, i.e., the compound requirement '{
t.n } ->' produces the return type as 'const std::size_t &' instead of 'const
std::size_t'. Which is inconsistent elsewhere (see the source code above).
Version: g++ (GCC) 11.0.0 20200910 (experimental)
Diagnostic messages:
bug-4.cpp:15:53: error: no matching function for call to ‘f(s<1>)’
15 | static_assert (std::is_same_v {})), std::size_t>);
| ^
bug-4.cpp:13:17: note: candidate: ‘template requires S
decltype(auto) f(auto:1)’
13 | decltype (auto) f (S v) { return v.n; };
| ^
bug-4.cpp:13:17: note: template argument deduction/substitution failed:
bug-4.cpp:13:17: note: constraints not satisfied
bug-4.cpp: In substitution of ‘template requires S
decltype(auto) f(auto:1) [with auto:1 = s<1>]’:
bug-4.cpp:15:53: required from here
bug-4.cpp:7:9: required for the satisfaction of ‘S’ [with auto:1 =
s<1>]
bug-4.cpp:7:13: in requirements with ‘T t’ [with T = s<1>]
bug-4.cpp:9:5: note: ‘t.n’ does not satisfy return-type-requirement, because
9 | { t.n } -> std::same_as ;
| ~~^
bug-4.cpp:9:5: error: deduced expression type does not satisfy placeholder
constraints
bug-4.cpp:9:5: note: constraints not satisfied
In file included from bug-4.cpp:1:
/home/dgorokho/gcc-trunk/trunk/dist/include/c++/11.0.0/concepts:57:15:
required for the satisfaction of ‘__same_as<_Tp, _Up>’ [with _Tp = const long
unsigned int&; _Up = const long unsigned int]
/home/dgorokho/gcc-trunk/trunk/dist/include/c++/11.0.0/concepts:62:13:
required for the satisfaction of ‘same_as’
/home/dgorokho/gcc-trunk/trunk/dist/include/c++/11.0.0/concepts:57:32: note:
the expression ‘is_same_v<_Tp, _Up> [with _Tp = const long unsigned int&; _Up =
const long unsigned int]’ evaluated to ‘false’
57 | concept __same_as = std::is_same_v<_Tp, _Up>;
| ~^~~
bug-4.cpp:15:53: error: no matching function for call to ‘f(s<1>)’
15 | static_assert (std::is_same_v {})), std::size_t>);
| ^
bug-4.cpp:13:17: note: candidate: ‘template requires S
decltype(auto) f(auto:1)’
13 | decltype (auto) f (S v) { return v.n; };
| ^
bug-4.cpp:13:17: note: template argument deduction/substitution failed:
bug-4.cpp:13:17: note: constraints not satisfied
bug-4.cpp: In substitution of ‘template requires S
decltype(auto) f(auto:1) [with auto:1 = s<1>]’:
bug-4.cpp:15:53: required from here
bug-4.cpp:7:9: required for the satisfaction of ‘S’ [with auto:1 =
s<1>]
bug-4.cpp:7:13: in requirements with ‘T t’ [with T = s<1>]
bug-4.cpp:9:5: note: ‘t.n’ does not satisfy return-type-requirement, because
9 | { t.n } -> std::same_as ;
| ~~^
bug-4.cpp:9:5: error: deduced expression type does not satisfy placeholder
constraints
bug-4.cpp:9:5: note: constraints not satisfied
In file included from bug-4.cpp:1:
/home/dgorokho/gcc-trunk/trunk/dist/include/c++/11.0.0/concepts:57:15:
required for the satisfaction of ‘__same_as<_Tp, _Up>’ [with _Tp = const long
unsigned int&; _Up = const long unsigned int]
/home/dgorokho/gcc-trunk/trunk/dist/include/c++/11.0.0/concepts:62:13:
required for the satisfaction of ‘same_as’
/home/dgorokho/gcc-trunk/trunk/dist/include/c++/11.0.0/concepts:57:32: note:
the expression ‘is_same_v<_Tp, _Up> [with _Tp = const long unsigned int&; _Up =
const long unsigned int]’ evaluated to ‘false’
57 | concept __same_as = std::is_same_v<_Tp, _Up>;
| ~^~~
bug-4.cpp:15:21: error: template argument 1 is invalid
15 | static_assert (std::is_same_v {})), std::size_t>);
| ^~~~
bug-4.cpp:16:16: error: static assertion failed
16 | static_assert (S >);
|^
bug-4.cpp:16:16: note: cons
Segmentation fault since 7fc49a5777943aab11e227136d00a836f28f12b2
Hi Jason et al, After a bisect I found that the commit 7fc49a5777943aab11e227136d00a836f28f12b2 causes a segmentation fault during my compilation: sqlpp11/include/sqlpp11/where.h: In substitution of ‘template template template using _new_statement_t = sqlpp::new_statement_t, T> [with Check = sqlpp::consistent_t; T = sqlpp::where_t; Policies = Policies; bool WhereRequired = WhereRequired]’: sqlpp11/include/sqlpp11/where.h:320:99: required from here sqlpp11/include/sqlpp11/where.h:320:99: internal compiler error: Segmentation fault 320 | auto unconditionally() const -> _new_statement_t> | ^~ 0xc9978f crash_signal ../../gcc/toplev.c:328 0x692b05 pop_nested_class() ../../gcc/cp/class.c:8184 0x7a3157 instantiate_template_1 ../../gcc/cp/pt.c:20853 0x79e0b4 instantiate_template(tree_node*, tree_node*, int) ../../gcc/cp/pt.c:20908 0x79e0b4 instantiate_alias_template ../../gcc/cp/pt.c:20946 0x79e0b4 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:15147 0x7a451f lookup_template_class_1 ../../gcc/cp/pt.c:9853 0x7a4bfc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/cp/pt.c:10119 0x7c154d finish_template_type(tree_node*, tree_node*, int) ../../gcc/cp/semantics.c:3408 0x768b7d cp_parser_template_id ../../gcc/cp/parser.c:16739 0x768dec cp_parser_class_name ../../gcc/cp/parser.c:23713 0x765b21 cp_parser_qualifying_entity ../../gcc/cp/parser.c:6776 0x765b21 cp_parser_nested_name_specifier_opt ../../gcc/cp/parser.c:6458 0x76d126 cp_parser_simple_type_specifier ../../gcc/cp/parser.c:18134 0x753e0d cp_parser_type_specifier ../../gcc/cp/parser.c:17792 0x7673c9 cp_parser_type_specifier_seq ../../gcc/cp/parser.c:22402 0x761954 cp_parser_type_id_1 ../../gcc/cp/parser.c:22219 0x7606ff cp_parser_trailing_type_id ../../gcc/cp/parser.c:22325 0x7606ff cp_parser_late_return_type_opt ../../gcc/cp/parser.c:22129 0x7606ff cp_parser_direct_declarator ../../gcc/cp/parser.c:21258 I hope this is enough since I am not experienced in GCC development. Thanks, Nuno
[Bug analyzer/96650] [11 Regression] ICE in on_fact, at analyzer/constraint-manager.cc:1785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96650 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:50ddbd0282e06614b29f0d3f3be5fbe70085a8bd commit r11-3212-g50ddbd0282e06614b29f0d3f3be5fbe70085a8bd Author: David Malcolm Date: Tue Sep 15 05:51:04 2020 -0400 analyzer: fix ICE when merging constraints w/o transitivity [PR96650] PR analyzer/96650 reports an assertion failure when merging the intersection of two sets of constraints, due to the resulting constraints being infeasible. It turns out that the two input sets were each infeasible if transitivity were considered, but -fanalyzer-transitivity was off. However for this case, the merging code was "discovering" the transitive infeasibility of the intersection of the constraints even when -fanalyzer-transitivity is off, triggering an assertion failure. I attempted various fixes for this, but each of them would have introduced O(N^2) logic into the constraint-handling code into the -fno-analyzer-transitivity case (with N == the number of constraints). This patch fixes the ICE by tweaking the assertion, so that we silently drop such constraints if -fanalyzer-transitivity is off. gcc/analyzer/ChangeLog: PR analyzer/96650 * constraint-manager.cc (merger_fact_visitor::on_fact): Replace assertion that add_constraint succeeded with an assertion that if it fails, -fanalyzer-transitivity is off. gcc/testsuite/ChangeLog: PR analyzer/96650 * gcc.dg/analyzer/pr96650-1-notrans.c: New test. * gcc.dg/analyzer/pr96650-1-trans.c: New test. * gcc.dg/analyzer/pr96650-2-notrans.c: New test. * gcc.dg/analyzer/pr96650-2-trans.c: New test.
[Bug target/96139] Vector element extract mistypes long long int down to long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Will Schmidt : https://gcc.gnu.org/g:04a9b796436c68a07c052805631e962a1126dcca commit r9-8872-g04a9b796436c68a07c052805631e962a1126dcca Author: Will Schmidt Date: Tue Sep 15 15:06:08 2020 -0500 [PATCH, rs6000] Fix vector long long subtype (PR96139) Hi, This corrects an issue with the powerpc vector long long subtypes. As reported by SjMunroe, when building some code with -Wall, and attempting to print an element of a "long long vector" with a long long printf format string, we will report an error because the vector sub-type was improperly defined as int. When defining a V2DI_type_node we use a TARGET_POWERPC64 ternary to define the V2DI_type_node with "vector long" or "vector long long". We also need to specify the proper sub-type when we define the type. Due to some file renames, This is a backport and rework of both [PATCH, rs6000] Fix vector long long subtype (PR96139) and [PATCH, rs6000] Testsuite fixup pr96139 tests PR target/96139 2020-09-03 Will Schmidt gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_init_builtin): Update V2DI_type_node and unsigned_V2DI_type_node definitions. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr96139-a.c: New test. * gcc.target/powerpc/pr96139-b.c: New test. * gcc.target/powerpc/pr96139-c.c: New test.
[Bug analyzer/96650] [11 Regression] ICE in on_fact, at analyzer/constraint-manager.cc:1785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96650 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
Re: Segmentation fault since 7fc49a5777943aab11e227136d00a836f28f12b2
On Tue, Sep 15, 2020 at 10:41:31PM +0100, Nuno Gonçalves via Gcc-bugs wrote: > Hi Jason et al, > > After a bisect I found that the commit > 7fc49a5777943aab11e227136d00a836f28f12b2 causes a segmentation fault > during my compilation: This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 > sqlpp11/include/sqlpp11/where.h: In substitution of ‘template WhereRequired> template template > using _new_statement_t = sqlpp::new_statement_t sqlpp::no_where_t, T> [with Check = > sqlpp::consistent_t; T = sqlpp::where_t; > Policies = Policies; bool WhereRequired = WhereRequired]’: > sqlpp11/include/sqlpp11/where.h:320:99: required from here > sqlpp11/include/sqlpp11/where.h:320:99: internal compiler error: > Segmentation fault > 320 | auto unconditionally() const -> > _new_statement_t> > | >^~ > 0xc9978f crash_signal > ../../gcc/toplev.c:328 > 0x692b05 pop_nested_class() > ../../gcc/cp/class.c:8184 > 0x7a3157 instantiate_template_1 > ../../gcc/cp/pt.c:20853 > 0x79e0b4 instantiate_template(tree_node*, tree_node*, int) > ../../gcc/cp/pt.c:20908 > 0x79e0b4 instantiate_alias_template > ../../gcc/cp/pt.c:20946 > 0x79e0b4 tsubst(tree_node*, tree_node*, int, tree_node*) > ../../gcc/cp/pt.c:15147 > 0x7a451f lookup_template_class_1 > ../../gcc/cp/pt.c:9853 > 0x7a4bfc lookup_template_class(tree_node*, tree_node*, tree_node*, > tree_node*, int, int) > ../../gcc/cp/pt.c:10119 > 0x7c154d finish_template_type(tree_node*, tree_node*, int) > ../../gcc/cp/semantics.c:3408 > 0x768b7d cp_parser_template_id > ../../gcc/cp/parser.c:16739 > 0x768dec cp_parser_class_name > ../../gcc/cp/parser.c:23713 > 0x765b21 cp_parser_qualifying_entity > ../../gcc/cp/parser.c:6776 > 0x765b21 cp_parser_nested_name_specifier_opt > ../../gcc/cp/parser.c:6458 > 0x76d126 cp_parser_simple_type_specifier > ../../gcc/cp/parser.c:18134 > 0x753e0d cp_parser_type_specifier > ../../gcc/cp/parser.c:17792 > 0x7673c9 cp_parser_type_specifier_seq > ../../gcc/cp/parser.c:22402 > 0x761954 cp_parser_type_id_1 > ../../gcc/cp/parser.c:22219 > 0x7606ff cp_parser_trailing_type_id > ../../gcc/cp/parser.c:22325 > 0x7606ff cp_parser_late_return_type_opt > ../../gcc/cp/parser.c:22129 > 0x7606ff cp_parser_direct_declarator > ../../gcc/cp/parser.c:21258 > > I hope this is enough since I am not experienced in GCC development. > > Thanks, > Nuno > Marek
[Bug target/96139] Vector element extract mistypes long long int down to long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96139 Will Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Will Schmidt --- fix committed. closing out.
[Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 Bug ID: 97060 Summary: Missing DW_AT_declaration=1 in dwarf data Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jolsa at redhat dot com Target Milestone: --- We are missing expected declaration tag - DW_AT_declaration : 1 for function in debug info data. The problem we see is: - fs/init.c calls vfs_getattr function - vfs_getattr is defined outside the fs/init.c - once compiled, debug info data for vfs_getattr should contain declaration tag - DW_AT_declaration : 1, but it's missing gcc version: gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3) Unfortunately the issue can be so far reproduced only inside container, I tried to narrow it down to single fs/init.o object. Following steps create fs/init.o binary in kernel tree within the container: # podman image pull registry.gitlab.com/cki-project/containers/builder-rawhide:latest # podman image list # podman run -it /bin/bash # git clone https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git --depth 1 # curl https://xci32.lab.eng.rdu2.redhat.com/cki-project/cki-pipeline/-/jobs/974002/artifacts/raw/artifacts/kernel-bpf-next-x86_64-cd04b04de119a222c83936f7e9dbd46a650cb688.config -o bpf-next/.config # cd bpf-next/ # make oldconfig # might need some ENTERs # make fs/ -j # gcc -Wp,-MMD,fs/.init.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/10/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-var-tracking-assignments -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -flive-patching=inline-clone -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -fcf-protection=none -Wno-packed-not-aligned -DKBUILD_MODFILE='"fs/init"' -DKBUILD_BASENAME='"init"' -DKBUILD_MODNAME='"init"' -c -o fs/init.o fs/init.c # readelf --debug fs/init.o ... <1><9145>: Abbrev Number: 46 (DW_TAG_subprogram) <9146> DW_AT_external: 1 <9146> DW_AT_name: (indirect string, offset: 0x531c): vfs_getattr <914a> DW_AT_decl_file : 7 <914b> DW_AT_decl_line : 3148 <914d> DW_AT_decl_column : 12 <914e> DW_AT_prototyped : 1 <914e> DW_AT_type: <0xa9> <9152> DW_AT_sibling : <0x916b> <2><9156>: Abbrev Number: 3 (DW_TAG_formal_parameter) <9157> DW_AT_type: <0x3573> <2><915b>: Abbrev Number: 3 (DW_TAG_formal_parameter) <915c> DW_AT_type: <0x893a> <2><9160>: Abbrev Number: 3 (DW_TAG_formal_parameter) <9161> DW_AT_type: <0x111> <2><9165>: Abbrev Number: 3 (DW_TAG_formal_parameter) <9166> DW_AT_type: <0x4c> When we link the final kernel binary the debug info data contains multiple records for vfs_getattr, and neither has 'declaration' tag and it confuses pahole tool that uses this data to get function records and skips declarations. The problem is for more functions, vfs_getattr is just one example.
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #19 from Fangrui Song ---
(In reply to Jakub Jelinek from comment #14)
> This doesn't really look like a good idea to me. Instead, perhaps ld's
> --gc-sections or new special option should just remove unused string
> literals from mergeable sections.
> With your patch, I bet you lose e.g. all tail merging. Consider:
> const char *used1 () { return "foo bar baz blah blah"; }
> in one TU and
> const char *used2 () { return "bar baz blah blah"; }
> in another. The linker necessarily knows which strings (or other data) in
> mergeable sections are used and which are unused.
I second Jakub's idea that the linker should perform the constant merge (which
is implemented in LLD): the cost of a section header (sizeof(Elf64_Shdr)=64) +
a section name (".rodata.xxx.str1.1") is quite large.
Created a GNU ld (and gold) feature request:
https://sourceware.org/bugzilla/show_bug.cgi?id=26622
[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #3 from Tobias Burnus ---
Created attachment 49222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49222&action=edit
Slightly reduced example, compile with gfortran -fopenmp -O1 -ftracer
Some testing; with gfortran -fopenmp -O1 -ftracer it shows something like:
-31 =?= 64
The expected output is the last value of the loop iteration ("lastprivate"),
i.e. (b-1+1)*2 = 32*2 = 64. – When running the target section on the host
(-foffload=disable) it works, which indicates either a shared-memory vs.
non-shared issue or an nvptx problem.
At a glance, the original dump looks fine; it seems as if either the
.omp_data_i_28(D)->d1 = d1_9;
.omp_data_i_28(D)->d2 = d2_11;
is not executed or the PHI handling goes wrong.
[Bug fortran/97061] New: [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061 Bug ID: 97061 Summary: [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Found when looking at PR95654 - reduced + modified version of libgomp.fortran/pr66199-5.f90. The following ICEs with "gfortran -fopenmp test.f90": 6 | u(d1) = 5 | internal compiler error: in omp_add_variable, at gimplify.c:6955 0x671359 omp_add_variable ../../repos/gcc/gcc/gimplify.c:6955 integer function f3 (a1, b1) integer :: a1, b1, d1 integer u(0:1023) !$omp teams distribute parallel do simd default(none) firstprivate (a1, b1) shared(u) lastprivate(d1) do d1 = a1, b1-1 u(d1) = 5 end do end That's the assert: /* The only combination of data sharing classes we should see is FIRSTPRIVATE and LASTPRIVATE. However, OpenACC permits reduction variables to be used in data sharing clauses. */ gcc_assert ((ctx->region_type & ORT_ACC) != 0 || ((nflags & GOVD_DATA_SHARE_CLASS) == (GOVD_FIRSTPRIVATE | GOVD_LASTPRIVATE)) || (flags & GOVD_DATA_SHARE_CLASS) == 0); Original dump: #pragma omp teams firstprivate(a1) firstprivate(b1) shared(u) default(none) #pragma omp distribute lastprivate(d1) #pragma omp parallel firstprivate(a1) firstprivate(b1) lastprivate(d1) shared(u) default(none) #pragma omp for nowait #pragma omp simd linear(d1:1) lastprivate(d1)
[Bug gcov-profile/97062] New: [gcov] Don't repeat display of inline functions in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97062 Bug ID: 97062 Summary: [gcov] Don't repeat display of inline functions in headers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me CC: marxin at gcc dot gnu.org Target Milestone: --- This is a minor display issue. >a.cc cat
[Bug fortran/97063] New: [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97063 Bug ID: 97063 Summary: [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xin@compiler-dev.com Target Milestone: --- Consider the following Fortran program: program p implicit none real(kind=16), dimension(6) :: arr1 real(kind=16), dimension(6, 10) :: arr2 real(kind=16), dimension(10) :: arr3, arr6 real(kind=16), dimension(3) :: arr4 real(kind=16), dimension(3, 10) :: arr5 integer :: i, j data arr1 /0.0_16, 1.0_16, 2.0_16, 3.0_16, 4.0_16, 5.0_16/ do i = 1, 6 do j = 1,10 arr2(i, j) = (i + j) * 1.0_16 end do end do write(*,*) "--arr3--:" arr3 = matmul(arr1(5:1:-2),arr2(5:1:-2, :)) write(*,'(5F5.1)') arr3 write(*,*) "--arr4--:" arr4 = arr1(5:1:-2) write(*,'(5F5.1)') arr4 write(*,*) "--arr6--:" arr6 = matmul(arr4, arr2(5:1:-2, :)) write(*,'(5F5.1)') arr6 end program Compiled with gfortran 10.1.0, the program prints: --arr3--: 44.0 53.0 62.0 71.0 80.0 89.0 98.0107.0116.0125.0 --arr4--: 4.0 2.0 0.0 --arr6--: 32.0 38.0 44.0 50.0 56.0 62.0 68.0 74.0 80.0 86.0 As you can see,the value of arr3 is differnet with arr6.
[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #17 from Fangrui Song --- The algorithm is Donald B. Johnson's "Finding all the elementary circuits of a directed graph" (1975). (Hawick and James's just implemented the same algorithm by changing the representation of graphs). I am wondering why we enumerate every elementary cycle, find the minimum edge, reduce edge weighs, and repeat the process. What do we lose if we don't use the costly algorithm? (The time complexity is O(n*e*(c+1)). However, many implementations (Boost and gcov.c) do not use a hash set for the blocked list, and thus I suspect the actual complexity is higher). Do we have other low-cost approaches? (e.g. repeatedly finding strongly connected components and reducing)
[Bug tree-optimization/94234] missed ccp folding for (addr + 8 * n) - (addr + 8 * (n - 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94234 Feng Xue changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Feng Xue --- Fixed.
[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Summary|ICE in subspan, at |[9/10/11 Regression] ICE in
|input.h:69 |subspan, at input.h:69
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-09-16
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
Reduced:
void
foo (char const *name)
{
/*
xx
*/ __builtin_printf ("%s", name);
}
[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #5 from Marek Polacek --- Started with r269125. Use -O to reproduce. Bizarrely, it goes away when -Wall is in effect!
[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #6 from Marek Polacek --- Candidate fix: --- a/gcc/input.c +++ b/gcc/input.c @@ -1461,6 +1461,8 @@ get_substring_ranges_for_loc (cpp_reader *pfile, size_t literal_length = finish.column - start.column + 1; /* Ensure that we don't crash if we got the wrong location. */ + if (start.column < 1) + return "line is too long"; if (line.length () < (start.column - 1 + literal_length)) return "line is not wide enough";
[Bug target/97019] rs6000:redundant rldicr fed to lvx/stvx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97019 --- Comment #2 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:e0d98ffd14487b7105de3d151122144086faa1fa commit r11-3217-ge0d98ffd14487b7105de3d151122144086faa1fa Author: Kewen Lin Date: Tue Sep 15 22:32:55 2020 -0500 rs6000: Remove useless insns fed into lvx/stvx [PR97019] This patch is to extend the existing function find_alignment_op to check all defintions of base_reg are AND operations with mask -16B to force the alignment. If all are satifised, it passes all AND operations and instructions to function recombine_lvx_pattern and recombine_stvx_pattern, they can remove all useless ANDs further. Bootstrapped/regtested on powerpc64le-linux-gnu P8. gcc/ChangeLog: PR target/97019 * config/rs6000/rs6000-p8swap.c (find_alignment_op): Adjust to support multiple defintions which are all AND operations with the mask -16B. (recombine_lvx_pattern): Adjust to handle multiple AND operations from find_alignment_op. (recombine_stvx_pattern): Likewise. gcc/testsuite/ChangeLog: PR target/97019 * gcc.target/powerpc/pr97019.c: New test.
[Bug target/97019] rs6000:redundant rldicr fed to lvx/stvx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97019 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Kewen Lin --- Should be fixed on latest trunk now.
[Bug fortran/97061] [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- If it is the FE that adds the linear clause, then it shouldn't when there is explicit lastprivate clause. This is a new thing in OpenMP 5.0, in 4.5 it was invalid to make the iterate anything but linear in this case, now it can be made private or lastprivate.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-09-16
Ever confirmed|0 |1
CC||jsm28 at gcc dot gnu.org
Status|UNCONFIRMED |WAITING
--- Comment #1 from Richard Biener ---
I guess that vfs_getattr is declared 'extern inline'. At least with
extern inline int foo (int i) { return i; }
int main()
{
foo (5);
}
I can reproduce this kind of DIE:
<1><52>: Abbrev Number: 4 (DW_TAG_subprogram)
<53> DW_AT_external: 1
<53> DW_AT_name: foo
<57> DW_AT_decl_file : 1
<58> DW_AT_decl_line : 1
<59> DW_AT_decl_column : 19
<5a> DW_AT_prototyped : 1
<5a> DW_AT_type: <0x4b>
<5e> DW_AT_low_pc : 0x0
<66> DW_AT_high_pc : 0xc
<6e> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<70> DW_AT_GNU_all_call_sites: 1
these "extern" inline functions are not really external, but I'm not sure
of a better representation of GNU extern inline functions.
Can you please provide preprocessed source of the fs/init.o TU?
[Bug libstdc++/97057] [11 regression] Error in build gcc after r11-3149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97057 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug driver/97058] invalid "cc1: warning: '-Werror=' argument '-funroll-completely-grow-size' is not valid for C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97058 --- Comment #1 from Richard Biener --- You're not supposed to use this flag but the behavior is indeed weird. The last part "not valid for C/C++" is due to the fact the option is not marked for any language: funroll-completely-grow-size Undocumented Var(flag_cunroll_grow_size) Optimization ; Internal undocumented flag, allow size growth during complete unrolling but the '-Werror=' argument part is really odd ;)
[Bug tree-optimization/97064] New: BB vectorization behaves sub-optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97064
Bug ID: 97064
Summary: BB vectorization behaves sub-optimal
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The testcase g++.dg/vect/slp-pr87105.cc ends in
_64 = MIN_EXPR <_32, _87>;
bBox_6(D)->x0 = _64;
_67 = MIN_EXPR <_33, _86>;
bBox_6(D)->y0 = _67;
_70 = MAX_EXPR <_36, _87>;
bBox_6(D)->x1 = _70;
_73 = MAX_EXPR <_39, _86>;
bBox_6(D)->y1 = _73;
thus feeding a 4 element store with a non-uniform SLP opportunity
starting with { MIN, MIN, MAX, MAX }. With 2-element vector type
vectorization this eventually gets vectorized by splitting the group
which is prioritized over just building the { MIN..., MAX } vector
from scalars but with 4-element vector type vectorization no splitting
is considered and we end up successfully vectorizing just the store
with never considering the smaller vector size.
So at the moment the testcase PASSes with SSE but fails with AVX.
[Bug fortran/97061] [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061 --- Comment #2 from Tobias Burnus --- I think I also got this ICE with an additional 'collapse(2)', which might indicate that a(nother) check is missing.
[Bug tree-optimization/97064] BB vectorization behaves sub-optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97064 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Last reconfirmed||2020-09-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Blocks||53947 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
