[Bug target/95488] Suboptimal multiplication codegen for v16qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95488 --- Comment #3 from Hongtao.liu --- (In reply to Richard Biener from comment #2) > (In reply to Hongtao.liu from comment #1) > > I think it's this TYPE_SIGN (TREE_TYPE (REG_EXPR (op1))). > > That's not reliable. Mutliplication shouldn't care about sign? We need to extend v16qi to v16hi first, extension does care about sign.
[Bug target/95488] Suboptimal multiplication codegen for v16qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95488 --- Comment #4 from Hongtao.liu --- (In reply to Hongtao.liu from comment #3) > (In reply to Richard Biener from comment #2) > > (In reply to Hongtao.liu from comment #1) > > > I think it's this TYPE_SIGN (TREE_TYPE (REG_EXPR (op1))). > > > > That's not reliable. Mutliplication shouldn't care about sign? I think you're right, as along as we only care about lower 8 bits, sign isn't a matter. > > We need to extend v16qi to v16hi first, extension does care about sign.
[Bug c/95492] New: Avoid recursive inlining for -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95492
Bug ID: 95492
Summary: Avoid recursive inlining for -O2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Test case from PR90949:
int puts(const char*);
void free(void*);
void* malloc(unsigned long);
#define NULL 0
struct Node
{
struct Node* child;
};
void walk(struct Node* module, int cleanup)
{
if (module == NULL) {
return;
}
if (!cleanup) {
puts("No cleanup");
}
walk(module->child, cleanup);
if (cleanup) {
free(module);
}
}
int main()
{
struct Node* node = malloc(sizeof(struct Node));
node->child = NULL;
walk(node, 1);
}
https://godbolt.org/z/aqVApt
Since GCC 10, GCC inlines recursion with -O2/-O3. With -O3, new bigger code is
justified, but for -O2, it is quite questionable whether GCC should inline it
or not (or possibly, less agressive "inlining" for -O2)
[Bug testsuite/94853] [10/11 regression] excess errors in gfortran.dg/analyzer/pr93993.f90 since r10-8012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94853 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #4 from Martin Liška --- Nay progress on this please?
[Bug tree-optimization/90949] [9 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 --- Comment #18 from Dávid Bolvanský --- Yes, PR95492
[Bug tree-optimization/95493] New: [10 Regression] test for vector members apparently reordered with assignment to vector members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493
Bug ID: 95493
Summary: [10 Regression] test for vector members apparently
reordered with assignment to vector members
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Test case (https://godbolt.org/z/egnkd7), compile with `-O2 -std=c++17`:
#include
struct verify
{
const bool m_failed = false;
[[gnu::noinline]] void print_hex(const void* x, int n) const
{
const auto* bytes = static_cast(x);
for (int i = 0; i < n; ++i)
__builtin_fprintf(stderr, (i && i % 4 == 0) ? "'%02x" : "%02x",
bytes[i]);
__builtin_fprintf(stderr, "\n");
}
template
verify(bool ok, const Ts&... extra_info) : m_failed(!ok)
{
if (m_failed)
(print_hex(&extra_info, sizeof(extra_info)), ...);
}
~verify()
{
if (m_failed)
__builtin_abort();
}
};
using K [[gnu::vector_size(16)]] = int;
int
main()
{
int count = 1;
asm("" : "+m"(count));
verify(count == 1, 0, "", 0);
{
struct SW
{
K d;
};
struct
{
SW d;
} xx;
SW& x = xx.d;
x = SW(); // [0, 0, 0, 0]
for (int i = 3; i >= 2; --i)
{
x.d[i] = -1; // [0, 0, 0, -1] ...
int a = [](K y) {
for (int j = 0; j < 4; ++j)
if (y[j] != 0)
return j;
return -1;
}(x.d);
verify(a == i, 0, 0, 0, 0, i, x);
}
}
}
The relevant code here is:
```
using K [[gnu::vector_size(16)]] = int;
K x = K(); // [0, 0, 0, 0]
int i = 3;
x[i] = -1; // [0, 0, 0, -1]
int j;
for (j = 0; j < 4; ++j)
if (x[j] != 0)
break;
if (i != j) abort();
```
In a larger testcase I could see the assignment `x[i] = -1` getting reordered
with the "count zero" function in the disassembled test case.
[Bug ipa/95492] Avoid recursive inlining for -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95492 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-06-03 CC||hubicka at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r10-3583-g562d1e9556777988. Can you please Honza provide explanation for it?
[Bug other/60158] powerpc: usage of the .data.rel.ro.local section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 --- Comment #7 from Joakim Tjernlund --- (In reply to Segher Boessenkool from comment #6) > The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9 > development. See corresponding mailing list threads[1,2,3] for details. > > [1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html > [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html > [3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html This is not SPE specific. More like powerpc or gcc
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #6 from Antony Lewis --- Thanks for looking in to it. I tried rebuilding my gcc8 docker and rerunning. It now reports GNU Fortran (GCC) 8.4.1 20200602, however the leak still seems to be there? https://travis-ci.org/github/cmbant/CAMB/jobs/660297689
[Bug tree-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493 Martin Liška changed: What|Removed |Added Known to work||9.3.0 CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|[10 Regression] test for|[10/11 Regression] test for |vector members apparently |vector members apparently |reordered with assignment |reordered with assignment |to vector members |to vector members since ||r10-7523-gb90061c6ec090c6b Last reconfirmed||2020-06-03 Ever confirmed|0 |1 Known to fail||10.1.0, 11.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-7523-gb90061c6ec090c6b.
[Bug middle-end/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.2 Component|tree-optimization |middle-end Keywords||alias Target||x86_64-linux-gnu --- Comment #2 from Andrew Pinski --- VIEW_CONVERT_EXPR(MEM[(struct SW &)&xx].d)[i.1_2] = -1; _4 = MEM[(struct SW &)&xx].d; y = _4; There is some aliasing issues with the store and the next load. THe tree level is correct, it goes wrong on the RTL level. (In reply to Martin Liška from comment #1) > Confirmed, started with r10-7523-gb90061c6ec090c6b. No just exposed.
[Bug c++/95477] [coroutines] coroutine result object not properly freed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95477 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-06-03 Status|UNCONFIRMED |NEW Target Milestone|--- |10.2 Keywords||wrong-code Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- thanks for the report it looks like I omitted a cleanup expression.
[Bug gcov-profile/95494] New: [11 regression] Several -fprofile-use tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494 Bug ID: 95494 Summary: [11 regression] Several -fprofile-use tests FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 Between 20200601 (e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90) and 20200602 (d3b6767dce45a7100e4cc32d2986a55f09a2cce2), several -fprofile-use tests started to FAIL on 32-bit Solaris/SPARC only: +FAIL: g++.dg/tree-prof/pr35545.C compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: g++.dg/tree-prof/pr35545.C execution,-fprofile-use -D_PROFILE_USE /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/tree-prof/pr35545.C: In member function 'virtual int B::foo()': /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/tree-prof/pr35545.C:16:15: warning: profile for function 'virtual int B::foo()' not found in profile data [-Wmissing-profile] /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/tree-prof/pr35545.C: In member function 'virtual int A::foo()': /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/tree-prof/pr35545.C:6:15: warning: profile for function 'virtual int A::foo()' not found in profile data [-Wmissing-profile] +FAIL: gcc.dg/tree-prof/indir-call-prof-2.c compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/indir-call-prof-2.c execution,-fprofile-use -D_PROFILE_USE /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c: In function 'sub1': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c:10:1: warning: profile for function 'sub1' not found in profile data [-Wmissing-profile] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c: In function 'add1': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-2.c:4:1: warning: profile for function 'add1' not found in profile data [-Wmissing-profile] +FAIL: gcc.dg/tree-prof/indir-call-prof-topn.c compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/indir-call-prof-topn.c execution, -fprofile-use -D_PROFILE_USE /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-topn.c: In function 'two': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-topn.c:14:1: warning: profile for function 'two' not found in profile data [-Wmissing-profile] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-topn.c: In function 'one': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-topn.c:8:1: warning: profile for function 'one' not found in profile data [-Wmissing-profile] +FAIL: gcc.dg/tree-prof/indir-call-prof.c compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/indir-call-prof.c execution,-fprofile-use -D_PROFILE_USE /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c: In function 'setp': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c:17:6: warning: profile for function 'setp' not found in profile data [-Wmissing-profile] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c: In function 'a2': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c:8:12: warning: profile for function 'a2' not found in profile data [-Wmissing-profile] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c: In function 'a1': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c:3:12: warning: profile for function 'a1' not found in profile data [-Wmissing-profile] +FAIL: gcc.dg/tree-prof/pr59003.c compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/pr59003.c execution,-fprofile-use -D_PROFILE_USE /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/pr59003.c: In function 'foo': /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/pr59003.c:9:10: error: corrupted value profile: stringops profile counter (28246016 out of 11) inconsistent with basic-block count (11) +FAIL: gcc.dg/tree-prof/val-prof-2.c scan-ipa-dump profile "Transformation done: div/mod by constant 256" +FAIL: gcc.dg/tree-prof/val-prof-6.c compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/val-prof-6.c execution,-fprofile-use -D_PROFILE_USE /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/tree-prof/val-prof-6.c:8:3: error: corrupted value profile: stringops profile counter (28246016 out of 1000) inconsistent with basic-block count (1000) All of 64-bit Solaris/SPARC, 32 and 64-bit Solaris/x86 are still ok. It seems highly probably that this was caused by changeset: 233568:8312a62869f6 user:Martin Liska date:
[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-06-03 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please test the current master? This patch could fix it: a04b7410d305800b747963ab940d2b1a602b5ddf
[Bug tree-optimization/95487] [10/11 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95487 --- Comment #3 from Jakub Jelinek --- (In reply to Richard Biener from comment #2) > Jakub, you added the scatter support - do you remember what the code tries to > do here? I've only added gathers myself (and only the AVX2-ish), scatters were added by Kirill and others from Intel. And the integer mask in vector boolean vs. normal vectors is a big pain.
[Bug target/68837] PowerPC switch statement performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68837 HaoChen Gui changed: What|Removed |Added CC||guihaoc at gcc dot gnu.org --- Comment #2 from HaoChen Gui --- (In reply to David Edelsohn from comment #0) > Improve performance of switch statements: > > 1) Heuristics for decision tree vs tablejump > > 2) Avoid sign extended lwa for offset I think #1 was already implemented in current GC. Jump tables coexists with conditional jumps. jump-table-max-growth-ratio-for-speed/size decide how large a jump table could be and case-values-threshold defines if a jump table is beneficial. An example of GIMPLE switch ;; GIMPLE switch case clusters: 35 37 JT(values:5 comparisons:5 range:8 density: 62.50%):65-72 JT(values:6 comparisons:6 range:12 density: 50.00%):111-122 For #2, the offset could be negative in a multiple jump table case. Right now it uses lwax and there is no overhead for sing extend, I think. Please correct me if I am wrong.
[Bug target/95421] [AArch64] Missing NEON functions documented on ARM's web site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95421 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70369
[Bug target/95399] [ARM] 32/64-bit vcvtnq_* functions are missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70369
[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493
Richard Biener changed:
What|Removed |Added
Component|middle-end |rtl-optimization
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> VIEW_CONVERT_EXPR(MEM[(struct SW &)&xx].d)[i.1_2] = -1;
> _4 = MEM[(struct SW &)&xx].d;
> y = _4;
>
> There is some aliasing issues with the store and the next load.
>
> THe tree level is correct, it goes wrong on the RTL level.
;; VIEW_CONVERT_EXPR(MEM[(struct SW &)&xx].d)[i.1_2] = -1;
(insn 28 27 29 (set (reg:DI 92)
(sign_extend:DI (reg:SI 83 [ i.1_2 ]))) "t.C":50:16 -1
(nil))
(insn 29 28 0 (set (mem/j:SI (plus:DI (plus:DI (mult:DI (reg:DI 92)
(const_int 4 [0x4]))
(reg/f:DI 77 virtual-stack-vars))
(const_int -32 [0xffe0])) [1 MEM[(struct ._anon_0
*)_42] S4 A32])
(const_int -1 [0x])) "t.C":50:16 -1
(nil))
;; y = _5;
(insn 30 29 31 (set (reg:V4SI 93)
(mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -32 [0xffe0])) [1 MEM[(struct SW
&)_42].d+0 S16 A128])) -1
(nil))
(insn 31 30 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -16 [0xfff0])) [1 MEM[(vector(4) int
*)_69]+0 S16 A128])
(reg:V4SI 93)) -1
(nil))
alias-sets look OK, the bases look sane as well. The only odd thing
is that (anon *) which might confuse path-based analysis.
PRE indeed decides that insn 29 does not affect the load in insn 30:
deleting insn with uid = 30.
PRE: redundant insn 30 (expression 3) in bb 4, reaching reg is 110
scanning new insn with uid = 146.
deleting insn with uid = 34.
PRE: redundant insn 34 (expression 1) in bb 5, reaching reg is 111
PRE: edge (13,4), copy expression 1
PRE: edge (13,4), copy expression 3
PRE: store updated with reaching reg (reg:V4SI 110 [ MEM[(struct SW &)_42].d
]):
(insn 109 108 110 13 (set (mem/c:V4SI (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffe0])) [1
MEM[(struct SW *)_42].d+0 S16 A128])
(reg:V4SI 103)) "t.C":47:7 1347 {movv4si_internal}
(expr_list:REG_DEAD (reg:V4SI 103)
(nil)))
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7523-gb90061c6ec090c6b.
>
> No just exposed.
[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
OK, so the issue is we're getting these MEM_ATTRs when expanding the base
as
(mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -32 [0xffe0])) [5 MEM[(struct ._anon_0 *)_42]+0
S16 A128])
and set_mem_attributes_minus_bitpos due to the variable array-ref wouldn't
assign any here but inherits the already set ones.
/* Default values from pre-existing memory attributes if present. */
refattrs = MEM_ATTRS (ref);
if (refattrs)
{
/* ??? Can this ever happen? Calling this routine on a MEM that
already carries memory attributes should probably be invalid. */
attrs.expr = refattrs->expr;
attrs.offset_known_p = refattrs->offset_known_p;
attrs.offset = refattrs->offset;
attrs.size_known_p = refattrs->size_known_p;
attrs.size = refattrs->size;
attrs.align = refattrs->align;
}
so the following fixes the issue, the MEM_ATTRs are not what the code
expects them to be set with otherwise. Because clearly offset_known_p
should be false.
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 2b790636366..0a72269e2ce 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2114,6 +2114,10 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, int
objectp,
}
while (TREE_CODE (t2) == ARRAY_REF);
+ attrs.expr = NULL_TREE;
+ attrs.offset_known_p = false;
+ attrs.offset = 0;
+ apply_bitpos = 0;
if (DECL_P (t2)
|| (TREE_CODE (t2) == COMPONENT_REF
/* For trailing arrays t2 doesn't have a size that
[Bug middle-end/94874] [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94874 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:93535a2b40367e6f68433295b37dc52c0e9c2c55 commit r11-873-g93535a2b40367e6f68433295b37dc52c0e9c2c55 Author: Tobias Burnus Date: Wed Jun 3 12:28:25 2020 +0200 [OpenMP] Fix mapping of artificial variables (PR94874) gcc/c-family/ChangeLog: * c-common.h (c_omp_predetermined_mapping): Declare. * c-omp.c (c_omp_predetermined_mapping): New. gcc/c/ChangeLog: * c-objc-common.h (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Redefine. gcc/cp/ChangeLog: * cp-gimplify.c (cxx_omp_predetermined_mapping): New. * cp-objcp-common.h (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Redfine. * cp-tree.h (cxx_omp_predetermined_mapping): Declare. gcc/fortran/ChangeLog: * f95-lang.c (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Redefine. * trans-openmp.c (gfc_omp_predetermined_mapping): New. * trans.h (gfc_omp_predetermined_mapping): Declare. gcc/ChangeLog: * gimplify.c (omp_notice_variable): Use new hook. * langhooks-def.h (lhd_omp_predetermined_mapping): Declare. (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Define (LANG_HOOKS_DECLS): Add it. * langhooks.c (lhd_omp_predetermined_sharing): Remove bogus unused attr. (lhd_omp_predetermined_mapping): New. * langhooks.h (struct lang_hooks_for_decls): Add new hook. gcc/testsuite/ChangeLog 2020-06-03 Thomas Schwinge Tobias Burnus PR middle-end/94874 * c-c++-common/gomp/pr94874.c: New.
[Bug middle-end/94874] [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94874 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Tobias Burnus --- Finally fixed.
[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493 --- Comment #5 from Richard Biener --- Now, the real issue is of course that we fail to properly expand the inner MEM_REF since get_inner_reference strips that away and so we expand the decl resulting in bogus mem_attrs being applied. That is, we like to fix the set_mem_attrs_minus_bitpos without clearing attrs.expr but that makes the testcase still fail. Now, in this particular case the MEM_ATTRs should be still fine (the access modification on the MEM_REF is a simple down-cast) so we _do_ have an underlying issue in path-based disambiguation I think. Or from the !MEM_OFFSET_KNOWN_P path in ao_ref_from_mem which makes the access appear as a full def of the structure (but that shouldn't be wrong here either). In aliasing_component_refs_p cmp_outer is zero (accesses have the same size), then aliasing_component_refs_walk figures cmp == 0 && same_p == 0 for record_type 0x76975e70 ._anon_0 and record_type 0x76975d20 SW. In the opposite direction it suddenly is cmp == 1 for vector_type 0x7696bdc8 K (size 128) and record_type 0x76975e70 ._anon_0 (size 128)!? That's because compare_type_sizes special-handling of arrays and vectors. So we get non-conclusive result here as well but maybe_match remains false (don't we need to set maybe_match to true here?) So we fall down to return (base2_alias_set == ref1_alias_set || alias_set_subset_of (base2_alias_set, ref1_alias_set)); but oddly enough we have base2_alias_set 4 and ref1_alias_set 1 here which does not match up as ref1_type has alias-set 5. That might be because we have MEM_KEEP_ALIAS_SET_P set on the RTX. Documented as /* 1 if RTX is a mem and we should keep the alias set for this mem unchanged when we access a component. Set to 1, or example, when we are already in a non-addressable component of an aggregate. */ #define MEM_KEEP_ALIAS_SET_P(RTX) \ this "optimization" defeats the assumptions by path-based disambiguation which expects a match between alias sets and components here. The flag is set because of the VIEW_CONVERT_EXPR. Ah, and we've updated the alias-set from the VIEW_CONVERT_EXPR(MEM[(struct SW &)&xx].d)[i.1_2] expression but choose to keep the original one (which had a different alias-set). That's another source of confusion for the path-based disambiguation. If we fix that down the drain store_field will break it again via 7249 if (!MEM_KEEP_ALIAS_SET_P (to_rtx) && MEM_ALIAS_SET (to_rtx) != 0) 7250set_mem_alias_set (to_rtx, alias_set); we can fix _that_ by adjusting the caller to preserve a MEM_ALIAS_SET if present rather than looking at the GENERIC tree again.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #7 from Antony Lewis --- However the reduced case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 now seems to be OK. However on trunk, the fix for 94361 seems to have introduced a leak that was not there before: https://travis-ci.org/github/cmbant/CAMB/jobs/692470383 (was fine from gcc source build from 5 days ago - I just reran it with the new docker image)
[Bug c/95495] New: ice in vect_slp_analyze_node_operations, at tree-vect-slp.c:2893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95495
Bug ID: 95495
Summary: ice in vect_slp_analyze_node_operations, at
tree-vect-slp.c:2893
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Somewhere between dates 20200528 and 20200529, this C code starts
to ice with gcc trunk and flag -O3 on x86_64.
typedef struct {
int a;
int b
} c;
d, f, g;
c e[4];
h() {
for (; f; f++) {
g += e[f].a >> 1 | e[f].a & 1;
d += e[f].b >> 1 | e[f].b & 1;
}
}
$ /home/dcb/gcc/results/bin/gcc -c -w -O3 bug618.c
during GIMPLE pass: vect
bug618.c: In function ‘h’:
bug618.c:7:1: internal compiler error: in vect_slp_analyze_node_operations, at
tree-vect-slp.c:2893
7 | h() {
| ^
0xf97f30 vect_slp_analyze_node_operations(vec_info*, _slp_tree*,
_slp_instance*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >&,
hash_set<_slp_tree*, false, default_hash_traits<_slp_
tree*> >&, vec*)
../../trunk.git/gcc/tree-vect-slp.c:2891
0xf9756f vect_slp_analyze_node_operations(vec_info*, _slp_tree*,
_slp_instance*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >&,
hash_set<_slp_tree*, false, default_hash_traits<_slp_
tree*> >&, vec*)
../../trunk.git/gcc/tree-vect-slp.c:2816
0xf9756f vect_slp_analyze_node_operations(vec_info*, _slp_tree*,
_slp_instance*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >&,
hash_set<_slp_tree*, false, default_hash_traits<_slp_
tree*> >&, vec*)
../../trunk.git/gcc/tree-vect-slp.c:2816
0xf970c6 vect_slp_analyze_operations(vec_info*)
../../trunk.git/gcc/tree-vect-slp.c:2937
[Bug tree-optimization/95489] Failure to optimize x && (x & y) to x & y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95489 --- Comment #2 from Marc Glisse --- (In reply to Richard Biener from comment #1) > (bit_and (ne (bit_and x_3 y_4) 0) (ne x_3 0)) This could be simplified > where I'd say we miss > > (bit_and (ne @0 integer_zerop) (ne @1 integer_zerop)) > > -> > > (ne (bit_and @0 @1) integer_zerop) This only seems possible for 1-bit types: 1!=0 & 2!0 is not (1&2)!=0 To me, this falls in the general category of (x!=a)?f(x):y where y happens to be f(a) and f is not as costly as a condition+jump. I handled a few such cases a while ago with neutral_element_p, but it could be much more general (I am not saying it is easy).
[Bug sanitizer/95496] New: [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496 Bug ID: 95496 Summary: [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48666&action=edit A testcase GCC 10.1 gave [hjl@gnu-cfl-2 tmp]$ gcc -Wall -S -O2 x.i -fsanitize=undefined In function ‘pe_print_idata’, inlined from ‘_bfd_pe_print_private_bfd_data_common’ at peXXigen.c:2979:3: peXXigen.c:1378:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1378:3: warning: null format string [-Wformat-overflow=] In function ‘pe_print_edata’, inlined from ‘_bfd_pe_print_private_bfd_data_common’ at peXXigen.c:2980:3: peXXigen.c:1713:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1719:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1716:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1719:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1719:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1737:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1744:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1740:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1744:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1744:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1747:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1750:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1750:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1755:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1760:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1760:3: warning: null format string [-Wformat-overflow=] peXXigen.c:1760:3: warning: null format string [-Wformat-overflow=] [hjl@gnu-cfl-2 tmp]$ GCC 9.3 is OK.
[Bug tree-optimization/95487] [10/11 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95487 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- I will have a closer look.
[Bug ipa/95492] Avoid recursive inlining for -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95492 --- Comment #2 from Richard Biener --- Note we're also doing IPA-CP cloning and apply the same recursive inlining there.
[Bug tree-optimization/95495] [11 Regression] ice in vect_slp_analyze_node_operations, at tree-vect-slp.c:2893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95495 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 Ever confirmed|0 |1 Last reconfirmed||2020-06-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Component|c |tree-optimization Summary|ice in |[11 Regression] ice in |vect_slp_analyze_node_opera |vect_slp_analyze_node_opera |tions, at |tions, at |tree-vect-slp.c:2893|tree-vect-slp.c:2893 Version|unknown |11.0 --- Comment #1 from Richard Biener --- Mine. And I have a fix.
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #4 from bouanto at zoho dot com --- Thanks for all your work. I'm now facing this issue with the builtin __atomic_load: libgccjit.so: error: unimplemented primitive type for builtin (type: BT_CONST_VOLATILE_PTR) Can you add support for this type as well, please?
[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Martin Liška --- > Can you please test the current master? > This patch could fix it: a04b7410d305800b747963ab940d2b1a602b5ddf Unfortunately, it doesn't make a difference.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #8 from Thomas Koenig --- Unfortunately, without a somewhat reduced test case, there is not a lot I can do :-( Could you run this under valgrind, pinpoint the memory leaks (somewhat) and then try to reduce this?
[Bug sanitizer/95496] [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-06-03 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It was caused by commit 22fca489eaf98f2691772b51773a1e4eb7bb4ef2 Author: Martin Sebor Date: Mon Aug 26 18:29:45 2019 + PR tree-optimization/83431 - -Wformat-truncation may incorrectly report trun cation gcc/ChangeLog:
[Bug sanitizer/95496] [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |10.2
[Bug c++/95497] New: [11 Regression] ICE: concepts with a fully known / complete type in requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497
Bug ID: 95497
Summary: [11 Regression] ICE: concepts with a fully known /
complete type in requires
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
the following code ICEs starting with gcc-11:
```c++
template
struct A{};
template
concept c =
requires(T t, A b) // note that A is independent of T
{
{ t += b };
};
```
https://godbolt.org/z/pQI1ee
Thank you!
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 bouanto at zoho dot com changed: What|Removed |Added CC||bouanto at zoho dot com --- Comment #2 from bouanto at zoho dot com --- I'd like to have inline asm support as well. I would see an API like this: For global asm: gcc_jit_context_add_module_asm(gcc_jit_context* ctxt, gcc_jit_location* loc, const char* asm) For local (in function) asm: gcc_jit_function* gcc_jit_block_add_inline_asm(gcc_jit_block* block, gcc_jit_location* loc, gcc_jit_type* return_type, int num_params, gcc_jit_params** params, const char* asm, const char* constraints, bool has_side_effects, bool align_stack, enum gcc_jit_asm_dialect dialect) This will return a function that can then be called as usual with gcc_jit_context_new_call. The return type of the function can either be void, a single value or a struct depending on the constraints. In my case I would need the asm dialects Intel and ATT. Maybe has_side_effects and align_stack could be rvalues: I'm not sure. Thanks.
[Bug jit/95498] New: unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 Bug ID: 95498 Summary: unhandled conversion Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48667&action=edit Reproducer for the bug Hi. The attached reproducer fails with the following error: libgccjit.so: error: unhandled conversion input expression: constant visited 1> requested type: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f5a56d20 precision:32 min max > libgccjit.so: error: unhandled conversion input expression: unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f591e888 precision:64 min max pointer_to_this > visited arg:0 visited arg:0 visited unsigned DI (null):0:0 size unit-size align:64 warn_if_not_align:0 context chain >> arg:1 readonly constant visited arg:0 arg:1 >> requested type: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f5a56d20 precision:32 min max > libgccjit.so: error: unhandled conversion input expression: requested type: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f591e690 precision:32 min max pointer_to_this > gcc_jit_result_release: NULL result Sorry for the size of the reproducer. If you need to, I can try making it smaller. Thanks to fix this bug.
[Bug gcov-profile/93623] No need to dump gcdas when forking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623 --- Comment #11 from calixte --- Why did you remove __gcov_flush ? FYI, we use it in Firefox to dump counters on SIGUSR1: https://searchfox.org/mozilla-central/source/tools/code-coverage/CodeCoverageHandler.cpp#49
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #9 from Dominique d'Humieres --- For the record: % gfc pr94361.f90 -fanalyzer pr94361.f90:24:0: 24 | end subroutine | Warning: leak of 'test.t.dat.data' [CWE-401] [-Wanalyzer-malloc-leak] 'leaker': events 1-11 | | 20 | subroutine Leaker | | |.. | 23 | allocate(Test%T%Dat(1)) | | | 24 | end subroutine | | | +--> '__final_debug_Testtype2': events 12-30 | | 30 | end module | | ~ | | | | | (18) state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | | (19) state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | | (20) state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | | (21) following 'true' branch... | | (24) state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | | (25) state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | | (26) state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | | (27) following 'true' branch... | '__final_debug_Testtype2': events 31-32 | f951: | (31): state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | (32): state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | '__final_debug_Testtype2': event 33 | f951: | (33): state of 'test.t.dat.data': 'start' -> 'nonnull' (origin: NULL) | '__final_debug_Testtype2': events 34-35 | | 30 | end module | | | <--+ | 'leaker': events 36-37 | | 24 | end subroutine | | | Is it a false positive or not?
[Bug fortran/80174] [meta-bug] Fortran lto issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80174 Bug 80174 depends on bug 68358, which changed state. Bug 68358 Summary: Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #19 from Dominique d'Humieres --- The failures are gone with Xcode 11. Closing as WONTFIX.
[Bug middle-end/95499] New: ICE: during GIMPLE pass: ssa / segfault in verify_ssa / OpenMP target with deferred-length CHARACTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95499
Bug ID: 95499
Summary: ICE: during GIMPLE pass: ssa / segfault in verify_ssa
/ OpenMP target with deferred-length CHARACTER
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 48668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48668&action=edit
Test case - compile with "gfortran -fopenmp"
The attached testcase, found when trying to test something else.
The following bit causes the problem:
character(len=:), allocatable :: str
!$omp target map(from:str)
Fails with GCC trunk as:
during GIMPLE pass: ssa
test.f90:15:0:
15 | deallocate (A, my_str)
|
internal compiler error: Segmentation fault
0xeb42af crash_signal
../../repos/gcc/gcc/toplev.c:328
0x10d8c14 verify_ssa(bool, bool)
../../repos/gcc/gcc/tree-ssa.c:1070
0xdda8d5 execute_function_todo
../../repos/gcc/gcc/passes.c:1992
0xddb57e execute_todo
../../repos/gcc/gcc/passes.c:2039
With the distro's GCC 7 + 9 + 10, I get ("gfortran-10 -foffload=disable
-fopenmp"):
during IPA pass: fnsummary
test.f90:15: internal compiler error: tree code ‘ssa_name’ is not supported in
LTO streams
In the debugger, I see:
Program received signal SIGSEGV, Segmentation fault.
verify_ssa (check_modified_stmt=check_modified_stmt@entry=true,
check_ssa_operands=check_ssa_operands@entry=true) at
../../repos/gcc/gcc/gimple.h:6626
6626 return gimple_code (g) == GIMPLE_NOP;
(gdb) list
6621/* Returns TRUE if statement G is a GIMPLE_NOP. */
6622
6623static inline bool
6624gimple_nop_p (const gimple *g)
6625{
6626 return gimple_code (g) == GIMPLE_NOP;
6627}
(gdb) bt
#0 verify_ssa (check_modified_stmt=check_modified_stmt@entry=true,
check_ssa_operands=check_ssa_operands@entry=true) at
../../repos/gcc/gcc/gimple.h:6626
#1 0x00d604a6 in execute_function_todo (fn=0x778cf0b0,
data=) at ../../repos/gcc/gcc/passes.c:1992
#2 0x00d611dd in do_per_function (data=0x8040, callback=0xd60230
) at ../../repos/gcc/gcc/passes.c:1640
#3 execute_todo (flags=32832) at ../../repos/gcc/gcc/passes.c:2039
#4 0x00d639a3 in execute_one_pass (pass=0x25b23d0) at
../../repos/gcc/gcc/passes.c:2539
[Bug tree-optimization/95487] [10/11 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95487 --- Comment #5 from Richard Biener --- We also fail to unswitch the outer loop on if (d) (probably simply because we don't unswitch outer loops). It's likely the invariantness of the condition that makes the problem. We're vectorizing [local count: 437450365]: # b_43 = PHI _46 = (int) b_43; _65 = &g[_46]; .MASK_STORE (_65, 32B, d.0_2, 0); b.3_25 = (unsigned short) b_43; _33 = b.3_25 + 2; b_24 = (short int) _33; if (b_24 >= 0) goto ; [11.00%] else goto ; [89.00%] [local count: 389330825]: goto ; [100.00%] where we use a scatter because we fail to analyze the evolution for g[b]. We don't get a vector boolean type for the mask because the "magic" here doesn't work this way. 1508 else if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op)) 1509 && VECTOR_BOOLEAN_TYPE_P (stmt_vectype)) 1510vector_type = truth_type_for (stmt_vectype); which does not consider that the mask in scatters might need a vector boolean type. But it appearantly does. Test coverage for this code seems to be non-existent though :/ I do have a patch that fixes the testcase though.
[Bug c++/95497] [11 Regression] ICE: concepts with a fully known / complete type in requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 CC||iains at gcc dot gnu.org
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #3 from David Malcolm --- Note to self: GCC's documentation for using asm from C: https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html Thanks for the suggestions. I'm not seeing how the proposed entrypoints in comment #2 would work; sorry. I suspect we'd need to closely mirror the "basic" and "extended" asm approaches from C linked to above (probably using the terms "basic" and "extended" in the entrypoint names, to signal to the developer that that's what the calls would be analogous to). I'm wary about basic asm at the top level (outside functions), given that libgccjit has such an unusual relationship with the rest of the compiler (it might work, but it might have unexpected snags). I think the extended asm would need be along the lines of gcc_jit_block_add_extended_asm (gcc_jit_block *block, ...something...); possibly with and without goto labels. Do you have a specific use-case in mind? Thanks
[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494 --- Comment #3 from Martin Liška --- Is there a compile farm machine I can test it on? Btw. can you please make a brief analysis why it fails (valgrind)?
[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95494 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Martin Liška --- > Is there a compile farm machine I can test it on? Sure: gcc211 should do the trick. > Btw. can you please make a brief analysis why it fails (valgrind)? Unfortunately not: the Solaris/x86 valgrind port has been abandoned and doesn't do anything useful, and there never was a sparc port.
[Bug other/60158] powerpc: usage of the .data.rel.ro.local section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 --- Comment #8 from Segher Boessenkool --- It does not happen on any target currently, and it has never happened on non-SPE targets before.
[Bug tree-optimization/95495] [11 Regression] ice in vect_slp_analyze_node_operations, at tree-vect-slp.c:2893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95495 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:779ae320bfadc5d867ecaeddf394838d546b57b9 commit r11-876-g779ae320bfadc5d867ecaeddf394838d546b57b9 Author: Richard Biener Date: Wed Jun 3 14:06:20 2020 +0200 tree-optimization/95495 - use SLP_TREE_REPRESENTATIVE in assertion This fixes a place where I missed to use SLP_TREE_REPRESENTATIVE after its introduction. 2020-06-03 Richard Biener PR tree-optimization/95495 * tree-vect-slp.c (vect_slp_analyze_node_operations): Use SLP_TREE_REPRESENTATIVE in the shift assertion. * gcc.dg/vect/pr95495.c: New testcase.
[Bug tree-optimization/95495] [11 Regression] ice in vect_slp_analyze_node_operations, at tree-vect-slp.c:2893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95495 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #10 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #9) > Is it a false positive or not? You probably need a higher optimization level with -fanalyzer, it doesn't show anything at -O. Nor does valgrind show anything. So, I'd say a false positive.
[Bug fortran/95500] New: Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 Bug ID: 95500 Summary: Segfault compiling extra interface on intrinsic Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vincent.lafage at in2p3 dot fr Target Milestone: --- Created attachment 48669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48669&action=edit Source file for the minimal test case When compiling the following sample minimal test case (named test_intrinsic.f90) program test_intrinsic implicit none intrinsic :: alog intrinsic :: dlog real (4), parameter :: one = 1 interface ln procedure :: alog, dlog end interface ln write (*, *) 'ln 1', ln (one) end program test_intrinsic through $ gfortran -Wall -Wextra test_intrinsic.f90 I ended-up with the following failure: test_intrinsic.f90:11:0: 11 | write (*, *) 'ln 1', ln (one) | internal compiler error: Segmentation fault 0x7f4068d23fdf ??? /build/glibc-TrjWJf/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7f4068d10bba __libc_start_main ../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. I confirm that it is a longstanding bug, as I get the same problem with gfortran-4.9, gfortran-5, gfortran-6, gfortran-7, gfortran-8 as well. (Trying with other brands of compiler, g95, pgfortran, flang, and an old ifort reported error without segfaulting) Getting the backtrace with valgrind: $ valgrind -s -v --leak-check=full --show-reachable=yes --show-leak-kinds=all --leak-resolution=high --num-callers=100 --trace-children=yes --track-fds=yes --log-file=Valgrind_gfortran_report4.txt gfortran -v -Wall -Wextra test_intrinsic.f90 … ==891734== 1 errors in context 1 of 1: ==891734== Invalid read of size 1 ==891734==at 0x135083C: gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool) (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x1385548: gfc_trans_transfer(gfc_code*) (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x130D669: ??? (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x137FA9C: ??? (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x130D689: ??? (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x133F1F5: gfc_generate_function_code(gfc_namespace*) (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x128CF26: gfc_parse_file() (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x1309D9F: ??? (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0x143CC26: ??? (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0xD9A415: toplev::main(int, char**) (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734==by 0xD9C4CE: main (in /usr/lib/gcc/x86_64-linux-gnu/9/f951) ==891734== Address 0x50 is not stack'd, malloc'd or (recently) free'd ==891734== ==891734== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) $ gfortran --version GNU Fortran (Debian 9.2.1-4) 9.2.1 20190821 $ uname -a Linux serval 5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux $ gfortran -v -Wall -Wextra test_intrinsic.f90 Driving: gfortran -v -Wall -Wextra test_intrinsic.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran 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='Debian 9.2.1-4' --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 20190821 (Debian 9.2.1-4) COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/9/f951 test_intrinsic.f90 -quiet -dumpbase test_intrinsic.f90 -mtune=generic -march=x86-64 -auxbase test_intrinsic -Wall -
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6d36cc21b69d952967a4df6653954f572a101796 commit r11-877-g6d36cc21b69d952967a4df6653954f572a101796 Author: David Malcolm Date: Wed Jun 3 08:59:23 2020 -0400 jit: implement BT_CONST_VOLATILE_PTR [PR 95306] gcc/jit/ChangeLog: PR jit/95306 * jit-builtins.c (builtins_manager::make_primitive_type): Implement BT_CONST_VOLATILE_PTR. gcc/testsuite/ChangeLog: PR jit/95306 * jit.dg/test-pr95306-builtin-types.c (create_code): Add test of getting __atomic_load.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #26 from Qing Zhao --- > --- Comment #25 from Martin Liška --- >> I will try to get more data on our real application. >> >> one question: why not just delete the entire records whose counter is zero >> and delete the entire file whose counter is zero? > > Because we need to distinguish in between situations where a function was > really not executed (counter == 0) and the situation where we miss profile for > a function. Understood. However, is it possible to just provide an option for the user to choose to just delete all the zero records and files in order to save more space? > > How exactly do you merge profiles? Do you run parallel invocation which can > take log2(N)? We run serial merge adding one at a time right now. Is it possible for gcov-merge to add a new functionality to automatically merge complete Set of subdirectories?
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #6 from David Malcolm --- I've added the type; hopefully the builtin works as expected.
[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95468
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Summary|ICE in expression sfinae|[8/9/10/11 Regression] ICE
||in expression sfinae
Keywords|ice-on-invalid-code |ice-on-valid-code
Target Milestone|--- |8.5
--- Comment #2 from Patrick Palka ---
(In reply to kab from comment #1)
> This was labeled as "ice-on-invalid-code". Am I missing something? I don't
> see anything invalid here.
I just now adjusted the label to be "ice-on-valid-code" instead.
This seems to be a regression relative to GCC 4.8, which compiles the testcase
successfully (with -std=c++11). We began ICEing on the testcase starting with
r0-122271.
Here is a reduced testcase:
template struct a { };
struct c {
template static constexpr bool condition() { return d; }
};
template
void foo() {
using A = a()>;
}
void bar() {
foo();
}
[Bug fortran/93814] [9/10/11 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814 --- Comment #6 from G. Steinmetz --- Following (valid) cases should also be considered (no ICE) : $ cat z2.f90 function f() character :: f, g entry g() end $ cat z3.f90 function f() bind(c) integer :: f, g entry g() bind(c) end $ cat z4.f90 function f() bind(c) real :: f, g entry g() bind(c) end
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from G. Steinmetz --- Also related : $ cat z1.f90 program p integer, parameter :: a(merge(2,3,.true.)) = 1, b = size(a) print *, rank(b) end $ cat z2.f90 program p integer, parameter :: a(merge(2,3,.true.)) = 1 integer, parameter :: b = size(a) print *, rank(b) end $ gfortran-11-20200531 -c z2.f90 f951: internal compiler error: Segmentation fault 0xbc37bf crash_signal ../../gcc/toplev.c:328 0x62d62b gfc_check_rank(gfc_expr*) ../../gcc/fortran/check.c:4577 0x669a0c do_check ../../gcc/fortran/intrinsic.c:4737 0x669a0c check_specific ../../gcc/fortran/intrinsic.c:4750 0x673d04 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4987 0x6c1bf3 resolve_unknown_f ../../gcc/fortran/resolve.c:2902 0x6c1bf3 resolve_function ../../gcc/fortran/resolve.c:3246 0x6c1bf3 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7040 0x6c872c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7007 0x6c872c gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11742 0x6d186f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10769 0x6c7508 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11732 0x6c9d97 resolve_codes ../../gcc/fortran/resolve.c:17257 0x6c9e5e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17292 0x6b1f9c resolve_all_program_units ../../gcc/fortran/parse.c:6245 0x6b1f9c gfc_parse_file() ../../gcc/fortran/parse.c:6492 0x6fdfff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/95501] New: ICE in gfc_match_pointer_assignment, at fortran/match.c:1422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95501 Bug ID: 95501 Summary: ICE in gfc_match_pointer_assignment, at fortran/match.c:1422 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181028 (error) and 20181104 (ICE) : $ cat z1.f90 program p integer, target :: a = 2 integer, pointer :: z z%kind => a%kind z%kind => a end $ cat z2.f90 program p character, target :: a = 'a' character, pointer :: z z%kind => a z%kind => a%kind z%len => a z%len => a%len a%kind => a%len a%len => a%kind end $ gfortran-11-20200531 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbc37bf crash_signal ../../gcc/toplev.c:328 0x686c67 gfc_match_pointer_assignment() ../../gcc/fortran/match.c:1422 0x6aa97b match_word ../../gcc/fortran/parse.c:65 0x6aa97b decode_statement ../../gcc/fortran/parse.c:362 0x6ac41a next_free ../../gcc/fortran/parse.c:1279 0x6ac41a next_statement ../../gcc/fortran/parse.c:1511 0x6ada6b parse_spec ../../gcc/fortran/parse.c:3922 0x6b083c parse_progunit ../../gcc/fortran/parse.c:5851 0x6b1f19 gfc_parse_file() ../../gcc/fortran/parse.c:6392 0x6fdfff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2020-06-03 CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 280157) +++ gcc/fortran/trans-expr.c(working copy) @@ -8789,6 +8789,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, if (expr->expr_type == EXPR_FUNCTION && ((expr->value.function.esym + && expr->value.function.esym->result && expr->value.function.esym->result->attr.pointer && !expr->value.function.esym->result->attr.dimension) || (!expr->value.function.esym && !expr->ref
[Bug fortran/95502] New: ICE in gfc_check_do_variable, at fortran/parse.c:4446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95502 Bug ID: 95502 Summary: ICE in gfc_check_do_variable, at fortran/parse.c:4446 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181028 (error) and 20181104 (ICE) : $ cat z1.f90 program p integer, pointer :: z nullify(z%kind) end $ cat z2.f90 program p complex, pointer :: z nullify(z%kind) ! nullify(z%re) ! nullify(z%im) end $ cat z3.f90 program p character, pointer :: z nullify(z%len) nullify(z%kind) end $ gfortran-11-20200531 -c z1.f90 f951: internal compiler error: Segmentation fault 0xbc37bf crash_signal ../../gcc/toplev.c:328 0x6aeed8 gfc_check_do_variable(gfc_symtree*) ../../gcc/fortran/parse.c:4446 0x6895ab gfc_match_nullify() ../../gcc/fortran/match.c:4625 0x6a7651 match_word ../../gcc/fortran/parse.c:65 0x6ab35d decode_statement ../../gcc/fortran/parse.c:527 0x6ac41a next_free ../../gcc/fortran/parse.c:1279 0x6ac41a next_statement ../../gcc/fortran/parse.c:1511 0x6ada6b parse_spec ../../gcc/fortran/parse.c:3922 0x6b083c parse_progunit ../../gcc/fortran/parse.c:5851 0x6b1f19 gfc_parse_file() ../../gcc/fortran/parse.c:6392 0x6fdfff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug middle-end/95499] ICE: during GIMPLE pass: ssa / segfault in verify_ssa / OpenMP target with deferred-length CHARACTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95499
--- Comment #1 from Tobias Burnus ---
Test case need the change (in line 40) to compile - sorry.
@@ -40 +40 @@
-if (any (array /= [(-2*i, i = 1, nn)])) error stop 2
+if (any (array /= [(-2*i, i = 1, 10)])) error stop 2
Shorter test case – but consider using the full one for the testsuite!
Remarks:
* As it, it fails as shown in comment 0
* When commenting the 'str = "…' it segfault in dominated_by_p
* When commenting that line + removes/comments-out the 'map(from:str)' clause,
it ICEs in expand_expr_real_1, at expr.c:10160
subroutine bar_str(str)
integer :: i
character(len=:), allocatable :: str
!$omp target map(from:str)
str = "abcdefghij"
!$omp do private(str)
do i = 1, 10
str(i:i) = achar(ichar('A') + i)
end do
!$omp end target
end
[Bug fortran/95503] New: ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95503 Bug ID: 95503 Summary: ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181028 (error) and 20181104 (ICE) : $ cat z1.f90 program p complex, target :: a = (1.0, 2.0) real, pointer, contiguous :: b => a%re end $ cat z2.f90 program p complex, target :: a real, pointer, contiguous :: b => a%re end $ gfortran-11-20200531 -c z1.f90 f951: internal compiler error: in gfc_is_simply_contiguous, at fortran/expr.c:5844 0x65d5a2 gfc_is_simply_contiguous(gfc_expr*, bool, bool) ../../gcc/fortran/expr.c:5844 0x65e5f7 gfc_check_pointer_assign(gfc_expr*, gfc_expr*, bool, bool) ../../gcc/fortran/expr.c:4349 0x65e93d gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*) ../../gcc/fortran/expr.c:4438 0x63d70e add_init_expr_to_sym ../../gcc/fortran/decl.c:1926 0x64762a variable_decl ../../gcc/fortran/decl.c:2990 0x64762a gfc_match_data_decl() ../../gcc/fortran/decl.c:6190 0x6aa9d3 match_word ../../gcc/fortran/parse.c:65 0x6aa9d3 decode_statement ../../gcc/fortran/parse.c:376 0x6ac41a next_free ../../gcc/fortran/parse.c:1279 0x6ac41a next_statement ../../gcc/fortran/parse.c:1511 0x6ada6b parse_spec ../../gcc/fortran/parse.c:3922 0x6b083c parse_progunit ../../gcc/fortran/parse.c:5851 0x6b1f19 gfc_parse_file() ../../gcc/fortran/parse.c:6392 0x6fdfff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/95504] New: ICE in transfer_array_component, at fortran/trans-io.c:2167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95504 Bug ID: 95504 Summary: ICE in transfer_array_component, at fortran/trans-io.c:2167 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r8 before 20180525 : $ cat z1.f90 program p type t(n) integer, len :: n integer, pointer :: a(:) end type type(t(3)) :: z print *, z end $ cat z2.f90 program p type t(n) integer, len :: n integer, allocatable :: a(:) end type type(t(3)) :: z print *, z end $ gfortran-11-20200531 -c z1.f90 z1.f90:7:0: 7 |print *, z | internal compiler error: Segmentation fault 0xbc37bf crash_signal ../../gcc/toplev.c:328 0x75e576 transfer_array_component ../../gcc/fortran/trans-io.c:2167 0x75de47 transfer_expr ../../gcc/fortran/trans-io.c:2471 0x7616a0 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2661 0x7017f7 trans_code ../../gcc/fortran/trans.c:2084 0x75f16e build_dt ../../gcc/fortran/trans-io.c:2026 0x7017d7 trans_code ../../gcc/fortran/trans.c:2056 0x72ad24 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6840 0x6b25e6 translate_all_program_units ../../gcc/fortran/parse.c:6306 0x6b25e6 gfc_parse_file() ../../gcc/fortran/parse.c:6545 0x6fdfff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95468 --- Comment #3 from Patrick Palka --- The reason we fail to compile the testcase when 'condition' is at class scope instead of at namespace scope is because in the former case, the template argument 'c::condition' is a CALL_EXPR to a BASELINK, and when doing instantiate_non_dependent_expr_internal on this CALL_EXPR, we don't semantically process the template argument 'bool(true)' within BASELINK because we never call tsubst_baselink because tsubst_copy exits early when args is NULL_TREE. We don't have this problem in the latter case where 'condition' is at namespace scope, because then the template argument 'condition' is a CALL_EXPR to a TEMPLATE_ID_EXPR, and TEMPLATE_ID_EXPRs are handled directly from tsubst_copy_and_build which doesn't do an early exit when args is NULL_TREE. A potential untested fix therefore is to also handle BASELINK directly from tsubst_copy_and_build: diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index d7f61289621..e15fca54823 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -19472,6 +19472,11 @@ tsubst_copy_and_build (tree t, case SCOPE_REF: RETURN (tsubst_qualified_id (t, args, complain, in_decl, /*done=*/true, /*address_p=*/false)); + +case BASELINK: + RETURN (tsubst_baselink (t, current_nonlambda_class_type (), + args, complain, in_decl)); + case ARRAY_REF: op1 = tsubst_non_call_postfix_expression (TREE_OPERAND (t, 0), args, complain, in_decl); Ideally we might want two versions of tsubst_baselink, one that does template argument substitution and another than additionally performs semantic processing?
[Bug fortran/95504] ICE in transfer_array_component, at fortran/trans-io.c:2167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95504 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- With a non-parameterized type instead : $ cat zz1.f90 program p type t integer :: n integer, pointer :: a(:) end type type(t) :: z print *, z end $ gfortran-11-20200531 -c zz1.f90 zz1.f90:7:13: 7 |print *, z | 1 Error: Data transfer element at (1) cannot have POINTER components unless it is processed by a defined input/output procedure
[Bug sanitizer/95496] [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496
Martin Sebor changed:
What|Removed |Added
Blocks||85741
--- Comment #2 from Martin Sebor ---
The instrumentation added by the sanitizers is known to lead to introducing
invalid code (typically by jump threading) that triggers spurious warnings.
The dump for the attached file shows a number of invalid calls to fprintf.
Some of those result in diagnostics (in fact, they all should).
The first one looks like this. Note the tests for null and the subsequent uses
of nulls in the fprintf calls:
_707 = section_618->name;
_708 = dcgettext ("bfd", "\nThe Export Tables (interpreted %s section
contents)\n\n", 5);
if (vfile_98(D) == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data103);
if (_708 == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data104);
fprintf (vfile_98(D), _708, _707);
_709 = dcgettext ("bfd", "Export Flags \t\t\t%lx\n", 5);
if (vfile_98(D) == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 7698574]:
if (_708 == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
# _992 = PHI <_1012(466), _709(223)>
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data106);
if (_992 == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 7698574]:
# _2952 = PHI <_709(223), _1227(500)>
if (_2952 == 0B)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
# _2558 = PHI <0B(225), 0B(226)>
__builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data107);
fprintf (vfile_98(D), 0B, _637); <<< null format: warning
The calls with the null format are first seen in the dom3 dump, just after
thread3. The instrumentation (and jump threading) and the warnings are
inherently incompatible. They need to cooperate to avoid the spurious
warnings. The sanitizers could mark up the code somehow to either keep jump
threading from doing what it does or to let the warnings know the calls were
synthesized. Until something like this is implemented the guidance we have
been giving to users is to expect false positives from the warnings when using
sanitizers (or disable the warnings).
$ gcc -O2 -S -fsanitize=undefined -fdump-tree-strlen=/dev/stdout peXXigen.c |
sed -n "/^_bfd_pe_print_private_bfd_data_commo/,/^}/p" | grep "fprintf (" |
grep 0B
fprintf (0B, "\nTime/Date\t\t%08lx", _26);
fprintf (0B, "\nMajorLinkerVersion\t%d\n", _2667);
fprintf (0B, "MinorLinkerVersion\t%d\n", _2958);
fprintf (0B, "\nSectionAlignment\t%08x\n", _2856);
fprintf (0B, "FileAlignment\t\t%08x\n", _2834);
fprintf (0B, "MajorOSystemVersion\t%d\n", _2815);
fprintf (0B, "MinorOSystemVersion\t%d\n", _2801);
fprintf (0B, "MajorImageVersion\t%d\n", _2787);
fprintf (0B, "MinorImageVersion\t%d\n", _2773);
fprintf (0B, "MajorSubsystemVersion\t%d\n", _2766);
fprintf (0B, "MinorSubsystemVersion\t%d\n", _2752);
fprintf (0B, "Win32Version\t\t%08x\n", _2738);
fprintf (0B, "SizeOfImage\t\t%08x\n", _2720);
fprintf (0B, "SizeOfHeaders\t\t%08x\n", _2708);
fprintf (0B, "CheckSum\t\t%08x\n", _2696);
fprintf (0B, "\nDllCharacteristics\t%08x\n", _946);
fprintf (0B, "\nLoaderFlags\t\t%08lx\n", _2618);
fprintf (0B, "NumberOfRvaAndSizes\t%08lx\n", _2594);
fprintf (0B, "Entry %1x ", j_2977);
fprintf (0B, " %08lx ", _696);
fprintf (vfile_98(D), 0B, _637);
fprintf (vfile_98(D), 0B, _643);
fprintf (vfile_98(D), 0B, _790, _780);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B, _676);
fprintf (vfile_98(D), 0B, _682);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B);
fprintf (0B, " %x", em_data_1082);
fprintf (0B, "Subsystem\t\t%08x", _2689);
fprintf (0B, _1020);
fprintf (0B, _721, _670);
fprintf (0B, _708, _707);
fprintf (0B, _851, _850, addr_852);
fprintf (0B, "Subsystem\t\t%08x", _2689);
fprintf (0B, "Magic\t\t\t%04x", _30);
fprintf (0B, "Magic\t\t\t%04x", _30);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B);
fprintf (vfile_98(D), 0B, _682);
fprintf (vfile_98(D), 0B, _682);
fprintf (vfile_98(D), 0B, _613, _606);
fprintf (vfile_98(D), 0B, _2485, _2483);
fprintf (vfile_98(D), 0B, _1136);
fprintf (vfile_98(D), 0B, _232);
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow
[Bug c++/95505] New: [coroutines] ICE assert with get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505
Bug ID: 95505
Summary: [coroutines] ICE assert with
get_return_object_on_allocation_failure
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at gmail dot com
Target Milestone: ---
https://gcc.godbolt.org/z/2LXQ2c
#include
struct dummy
{
struct promise_type
{
dummy get_return_object() const noexcept { return {}; }
static dummy get_return_object_on_allocation_failure() noexcept {
return {}; }
std::suspend_always initial_suspend() const noexcept { return {}; }
std::suspend_never final_suspend() const noexcept { return {}; }
void return_void() const noexcept {}
void unhandled_exception() const noexcept {}
};
};
dummy foo()
{
co_return;
}
int main() {}
source>: In function 'dummy foo()':
:20:1: internal compiler error: tree check: expected call_expr, have
error_mark in morph_fn_to_coro, at cp/coroutines.cc:4050
20 | }
| ^
[Bug tree-optimization/95490] [10/11 Regression] writing 1 byte into a region of size 0 [-Wstringop-overflow=] since r10-5451-gef29b12cfbb4979a89b3cbadbf485a77c8fd8fce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95490 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE Blocks||88443 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Sebor --- This is in all likelihood a duplicate of pr95353. The patch I posted for it yesterday (https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547124.html) eliminates the warnings. *** This bug has been marked as a duplicate of bug 95353 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/95353] [10/11 Regression] spurious -Wstringop-overflow writing to a trailing array plus offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 --- Comment #10 from Martin Sebor --- *** Bug 95490 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 95490, which changed state. Bug 95490 Summary: [10/11 Regression] writing 1 byte into a region of size 0 [-Wstringop-overflow=] since r10-5451-gef29b12cfbb4979a89b3cbadbf485a77c8fd8fce https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95490 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279 --- Comment #14 from joseph at codesourcery dot com --- I think it's invalid to refer to element (size_t)-1 of an array; that the actual integer value used has to be within the range of available array elements. It's entirely possible that such an invalid usage is nevertheless widespread in practice.
[Bug middle-end/95485] missing warning writing into function text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95485 --- Comment #3 from Martin Sebor --- Ah, yes, -Wpedantic does detect the invalid conversion. But few projects use -Wpedantic (GCC itself doesn't) and enabling the warning in -Wall or -Wextra would likely lead to lots of noise for code that converts between object and function pointers (POSIX requires it to work). A warning implemented in a front end can also only detect questionable conversions but not the actual writes, which is what the warning I'm working on does (i.e., detect stores into read-only storage).
[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279 --- Comment #15 from Andrew Pinski --- (In reply to jos...@codesourcery.com from comment #14) > I think it's invalid to refer to element (size_t)-1 of an array; that the > actual integer value used has to be within the range of available array > elements. But this case is: (array + 1) + (size_t)-1 That is the question there.
[Bug middle-end/95506] New: [OpenMP] omp target – private clause and allocatables – unallocated or reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95506 Bug ID: 95506 Summary: [OpenMP] omp target – private clause and allocatables – unallocated or reallocation Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Found when playing around with PR95499 – which is about ICEs. The following program fails at run time – the actual argument is not allocated – hence, 'str = "a"' will allocate str on assignment if (*str != 0B) goto L.1; *str = (character(kind=1)[1:*_str] *) __builtin_malloc (1); goto L.2; However, if '*str == NULL' the code crashes, likewise, if the 'str' is allocated to a different length (e.g. 'my_str = "ab"' + 'str = "a"' + change 'len=5' to 'len=:'). As 'str' is private, I think the (re)allocation of 'str' should be fine, shouldn't it? program main implicit none character(len=5), allocatable :: my_str ! my_str = "b" ! << commented, i.e. unallocated call bar_str(my_str) contains subroutine bar_str(str) integer :: i character(len=5), allocatable :: str !$omp target private(str) str = "a" print *, str !$omp end target end end
[Bug middle-end/95499] ICE: during GIMPLE pass: ssa / segfault in verify_ssa / OpenMP target with deferred-length CHARACTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95499 Tobias Burnus changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- See also PR 95506 which is vaguely related.
[Bug target/94986] missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from Wilco ---
(In reply to Arnd Bergmann from comment #0)
> I reported a bug against clang for a Linux kernel failure, but
> it was suggested that the clang behavior is probably correct in this corner
> case while gcc gets it wrong, see https://bugs.llvm.org/show_bug.cgi?id=45826
>
> echo 'void f(void) { asm("mov r7, #0" ::: "r7"); }' | arm-linux-gnueabi-gcc
> -march=armv7-a -O2 -mthumb -pg -S -xc -
>
> silently accepts an inline asm statement that clobbers the frame pointer,
> but gcc rejects the same code if any of '-O0', '-fomit-frame-pointer' or
> 'fno-omit-frame-pointer' are used:
>
> : In function 'f':
> :1:44: error: r7 cannot be used in 'asm' here
>
> If using r7 in this case is indeed invalid, we need to ensure the kernel
> does not do this, and having gcc reject it would be helpful.
GCC will reject it if you explicitly enable the frame pointer. The logic seems
wrong in that it doesn't report an error if the frame pointer is implicitly
enabled via -pg. As a workaround for the kernel, just use -pg and
-fno-omit-frame-pointer together.
Corrupting a frame pointer loses the ability to follow the frame chain, similar
to a function built with -fomit-frame-pointer which will use r7 as a general
purpose register.
However this always reports an error since this corruption of the frame pointer
will cause a crash:
int *f(int x) { asm("mov r7, #0" ::: "r7"); return __builtin_alloca (x); }
[Bug sanitizer/95496] [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87884 --- Comment #3 from Martin Sebor --- See also pr87884.
[Bug middle-end/95507] New: [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Bug ID: 95507 Summary: [meta-bug] bogus/missing -Wnonnull Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Meta-bug for -Wnonnull false positives and negatives.
[Bug c++/95508] New: [10/11 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508
Bug ID: 95508
Summary: [10/11 Regression] ICE on unexpected expression
implicit_conv_expr since r10-7096
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r10-7096-gd417b4f5414d9076300ab41974a14424f722688c the following testcase
ICEs:
template
struct A;
template
struct B {
operator int () { return 0; }
};
template <>
struct A : B {};
struct D {
template
int foo () { return e[f]; }
int e[6];
A f;
};
rh1837006.C: In member function ‘int D::foo()’:
rh1837006.C:11:26: internal compiler error: unexpected expression
‘(int)((D*)this)->D::f’ of kind implicit_conv_expr
11 | int foo () { return e[f]; }
| ^
0xaf874b cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6541
0xaf8cef cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6746
0xafd0db maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7019
0xcc3e00 cp_build_array_ref(unsigned int, tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:3568
...
[Bug c++/95508] [10/11 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.2 Priority|P3 |P2 Last reconfirmed||2020-06-03 Status|UNCONFIRMED |NEW
[Bug target/94986] missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment #2 from nsz at gcc dot gnu.org ---
on arm the -pg abi is
func:
push {lr}
bl _gnu_mcount_nc
...
so no frame pointer is involved, -pg implying
-fno-omit-frame-pointer is a historical mistake i think
(because some targets required fp for -pg, but most don't).
ideally r7 clobber would just work with -pg -fomit-frame-pointer.
the alloca problem is a separate issue (that r7 clobber may not
work with alloca).
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Martin Sebor changed: What|Removed |Added Last reconfirmed||2020-06-03 Ever confirmed|0 |1 Target Milestone|--- |3.3 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- -Wnonnull was introduced in r53790 which according to the manual was in the GCC 3.3 time frame.
[Bug c++/95508] [10/11 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95502
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Last reconfirmed||2020-06-03
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Fixes z1.f90. May fix others.
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 280157)
+++ gcc/fortran/parse.c (working copy)
@@ -4440,6 +4440,9 @@ gfc_check_do_variable (gfc_symtree *st)
{
gfc_state_data *s;
+ if (!st)
+return 0;
+
for (s=gfc_state_stack; s; s = s->previous)
if (s->do_variable == st)
{
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -3784,6 +3784,9 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *
int proc_pointer;
bool same_rank;
+ if (!lvalue->symtree)
+return false;
+
lhs_attr = gfc_expr_attr (lvalue);
if (lvalue->ts.type == BT_UNKNOWN && !lhs_attr.proc_pointer)
{
[Bug tree-optimization/95487] [10 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95487 Richard Biener changed: What|Removed |Added Known to work||11.0 Known to fail||10.1.0 Summary|[10/11 Regression] ICE: |[10 Regression] ICE: |verify_gimple failed|verify_gimple failed |(error: invalid vector |(error: invalid vector |types in nop conversion)|types in nop conversion) |with -O3|with -O3 |-march=skylake-avx512 since |-march=skylake-avx512 since |r10-1052-gc29c92c789d93848 |r10-1052-gc29c92c789d93848 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/95487] [10/11 Regression] ICE: verify_gimple failed (error: invalid vector types in nop conversion) with -O3 -march=skylake-avx512 since r10-1052-gc29c92c789d93848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95487 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:887c45fb5b047171e82710baa51108d5c210eb42 commit r11-878-g887c45fb5b047171e82710baa51108d5c210eb42 Author: Richard Biener Date: Wed Jun 3 15:51:29 2020 +0200 tree-optimization/95487 - use a truth type for scatter masks This makes sure to get a truth type for scatter masks even when they are invariant. 2020-06-03 Richard Biener PR tree-optimization/95487 * tree-vect-stmts.c (vectorizable_store): Use a truth type for the scatter mask. * g++.dg/vect/pr95487.cc: New testcase.
[Bug target/94986] missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
Wilco changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Wilco ---
(In reply to nsz from comment #2)
> on arm the -pg abi is
>
> func:
> push {lr}
> bl _gnu_mcount_nc
> ...
>
> so no frame pointer is involved, -pg implying
> -fno-omit-frame-pointer is a historical mistake i think
> (because some targets required fp for -pg, but most don't).
Right, so the claim that -pg implies -fno-omit-frame-pointer is wrong, and that
means there is no bug in GCC. Looking at the latest docs, there is no mention
of frame pointer for the -pg option, and neither does -fomit-frame-pointer
discuss -pg. So this dependency must have been removed some time ago.
> ideally r7 clobber would just work with -pg -fomit-frame-pointer.
> the alloca problem is a separate issue (that r7 clobber may not
> work with alloca).
GCC correctly reports the error for that. So this can be closed then.
[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95501
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-06-03
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Fixes z1.f90 and z2.90.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -1394,7 +1394,7 @@ gfc_match_pointer_assignment (void)
gfc_matching_procptr_assignment = 0;
m = gfc_match (" %v =>", &lvalue);
- if (m != MATCH_YES)
+ if (m != MATCH_YES || !lvalue->symtree)
{
m = MATCH_NO;
goto cleanup;
[Bug c++/86568] -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-06-03
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
Known to fail||10.1.0, 11.0, 9.2.0
Blocks||95507
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
Confirmed. The problem isn't unique to -Wnonnull but affects other warnings as
well. An example involving -Walloc-size-larger-than is below.
The middle end warnings use the location of the call when they should instead
be using the location of the argument (when it has one).
$ cat z.c && gcc -O2 -S -Wall -Wpedantic z.c
typedef __SIZE_TYPE__ size_t;
__attribute__ ((alloc_size (2))) void* f (const char*, size_t, int);
void* g (void)
{
size_t n = (size_t)-1 / 2;
return f ("foo", n + 1, 0);
}
z.c: In function ‘g’:
z.c:9:10: warning: argument 2 value ‘9223372036854775808’ exceeds maximum
object size 9223372036854775807 [-Walloc-size-larger-than=]
9 | return f ("foo", n + 1, 0);
| ^~~
z.c:3:40: note: in a call to allocation function ‘f’ declared here
3 | __attribute__ ((alloc_size (2))) void* f (const char*, size_t, int);
|^
I'm not too familiar with the front end implementation but it too looks like it
uses the location of the call. The patch below produces the (almost) expected
output for the simple test case. The argument numbers are still off.
index b1379faa412..9c5e76c1e59 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5497,7 +5497,10 @@ check_nonnull_arg (void *ctx, tree param, unsigned
HOST_WIDE_INT param_num)
/* Diagnose the simple cases of null arguments. */
if (integer_zerop (fold_for_warn (param)))
{
- warning_at (pctx->loc, OPT_Wnonnull, "null argument where non-null "
+ location_t loc
+ = EXPR_HAS_LOCATION (param) ? EXPR_LOCATION (param) : pctx->loc;
+
+ warning_at (loc, OPT_Wnonnull, "null argument where non-null "
"required (argument %lu)", (unsigned long) param_num);
pctx->warned_p = true;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug target/94986] missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
--- Comment #4 from Nick Desaulniers ---
(In reply to nsz from comment #2)
> on arm the -pg abi is
>
> func:
> push {lr}
> bl _gnu_mcount_nc
> ...
>
> so no frame pointer is involved, -pg implying
> -fno-omit-frame-pointer is a historical mistake i think
> (because some targets required fp for -pg, but most don't).
>
> ideally r7 clobber would just work with -pg -fomit-frame-pointer.
> the alloca problem is a separate issue (that r7 clobber may not
> work with alloca).
Should GCC change this for aaarch32 then (rather than closing the bug)?
[Bug sanitizer/95496] [10/11 Regression] Bogus -Wformat-overflow= warnings with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496 --- Comment #4 from Jakub Jelinek --- (In reply to Martin Sebor from comment #2) > The instrumentation added by the sanitizers is known to lead to introducing > invalid code (typically by jump threading) that triggers spurious warnings. I don't think this is accurate description, the instrumentation doesn't lead to introduction of any invalid code, all it leads to is due to the instrumentation some code is less optimized. It is the property of jump threading that it often can result in code that will actually never be executed (i.e. dead code), that can happen easily both with sanitization or if one adds whatever the sanitizer adds by hand. And then the question is if the compiler is able to find out the code is dead and optimize it away before these warnings warn about it.
[Bug target/94986] missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986 --- Comment #5 from nsz at gcc dot gnu.org --- (In reply to Nick Desaulniers from comment #4) > (In reply to nsz from comment #2) > > ideally r7 clobber would just work with -pg -fomit-frame-pointer. > > the alloca problem is a separate issue (that r7 clobber may not > > work with alloca). > > Should GCC change this for aaarch32 then (rather than closing the bug)? yes, but that's bug 69690.
[Bug fortran/67938] ICE on using assumed rank character with some intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67938 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:8d57c30611b05a89fd265f6c0a74fe829c21cd34 commit r11-879-g8d57c30611b05a89fd265f6c0a74fe829c21cd34 Author: José Rui Faustino de Sousa Date: Wed Jun 3 19:33:11 2020 +0200 Simple patch only add assumed-rank to the list of possible attributes. gcc/fortran/ChangeLog: 2020-06-03 José Rui Faustino de Sousa PR fortran/95214 PR fortran/66833 PR fortran/67938 * trans-expr.c (gfc_maybe_dereference_var): Add assumed-rank to character dummy arguments list of possible attributes. gcc/testsuite/ChangeLog: 2020-06-03 José Rui Faustino de Sousa PR fortran/95214 PR fortran/66833 PR fortran/67938 * gfortran.dg/PR95214.f90: New test.
[Bug fortran/95214] ICE on assumed-rank character array with select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95214 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:8d57c30611b05a89fd265f6c0a74fe829c21cd34 commit r11-879-g8d57c30611b05a89fd265f6c0a74fe829c21cd34 Author: José Rui Faustino de Sousa Date: Wed Jun 3 19:33:11 2020 +0200 Simple patch only add assumed-rank to the list of possible attributes. gcc/fortran/ChangeLog: 2020-06-03 José Rui Faustino de Sousa PR fortran/95214 PR fortran/66833 PR fortran/67938 * trans-expr.c (gfc_maybe_dereference_var): Add assumed-rank to character dummy arguments list of possible attributes. gcc/testsuite/ChangeLog: 2020-06-03 José Rui Faustino de Sousa PR fortran/95214 PR fortran/66833 PR fortran/67938 * gfortran.dg/PR95214.f90: New test.
[Bug fortran/66833] ICE on assumed-rank character actual argument to intrinsic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66833 --- Comment #3 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:8d57c30611b05a89fd265f6c0a74fe829c21cd34 commit r11-879-g8d57c30611b05a89fd265f6c0a74fe829c21cd34 Author: José Rui Faustino de Sousa Date: Wed Jun 3 19:33:11 2020 +0200 Simple patch only add assumed-rank to the list of possible attributes. gcc/fortran/ChangeLog: 2020-06-03 José Rui Faustino de Sousa PR fortran/95214 PR fortran/66833 PR fortran/67938 * trans-expr.c (gfc_maybe_dereference_var): Add assumed-rank to character dummy arguments list of possible attributes. gcc/testsuite/ChangeLog: 2020-06-03 José Rui Faustino de Sousa PR fortran/95214 PR fortran/66833 PR fortran/67938 * gfortran.dg/PR95214.f90: New test.
[Bug fortran/66833] ICE on assumed-rank character actual argument to intrinsic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66833 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Koenig --- Fixed on master, thank you for the bug report!
[Bug fortran/67938] ICE on using assumed rank character with some intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67938 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Thomas Koenig --- Fixed on master, thank you for the bug report!
