[Bug tree-optimization/102684] [missed optimization] std::min_element / ranges::min_element does not get optimized away with std::gcd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102684
--- Comment #4 from Andrew Pinski ---
Here is what optimized looks like on the trunk (after the main->f change):
[local count: 1073741824]:
_54 = operator new (16);
MEM [(char * {ref-all})_54] = 0xa000600040002;
[local count: 3043903040]:
# __m_103 = PHI <1(2), __m_85(6)>
# __n_104 = PHI <5(2), __n_111(6)>
if (__m_103 > __n_104)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 1521951520]:
__n_107 = __n_104 - __m_103;
if (__n_107 == 0)
goto ; [22.00%]
else
goto ; [78.00%]
[local count: 1014634349]:
_109 = __m_103 << 1;
_41 = (int) _109;
operator delete (_54, 16);
return _41;
[local count: 2709073704]:
# __m_85 = PHI <__m_103(4), __n_104(7)>
# __n_30 = PHI <__n_107(4), __n_87(7)>
_110 = __builtin_ctz (__n_30);
__n_111 = __n_30 >> _110;
goto ; [100.00%]
[local count: 1521951520]:
__n_87 = __m_103 - __n_104;
goto ; [100.00%]
There seems to be some VRP missing inside the loop.
[Bug tree-optimization/102684] [missed optimization] std::min_element / ranges::min_element does not get optimized away with std::gcd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102684 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/102697] [Diagnostics] overflow warning missing after O2 vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102697
--- Comment #1 from Hongtao.liu ---
Change i to 0, still missing warning after vectorization
before vectorization
void max_B6_B4 (int i, struct B4_B6 * pb4_b6)
{
char * d;
char * q;
char * p;
[local count: 1073741824]:
[../test4.c:10:7] p_2 = [../test4.c:10:11] &[../test4.c:10:17]
pb4_b6_1(D)->b6;
[../test4.c:11:7] q_3 = [../test4.c:11:11] &[../test4.c:11:17]
pb4_b6_1(D)->b4;
[../test4.c:12:9] d_4 = MAX_EXPR ;
[../test4.c:14:8] MEM [(char *)d_4 + 3B] = 0;
[../test4.c:18:1] return;
after vectorization:
;; Function max_B6_B4 (max_B6_B4, funcdef_no=0, decl_uid=4060, cgraph_uid=1,
symbol_order=0)
void max_B6_B4 (int i, struct B4_B6 * pb4_b6)
{
char * d;
char * q;
char * p;
[local count: 1073741824]:
[test4.c:10:7] p_2 = [test4.c:10:11] &[test4.c:10:17] pb4_b6_1(D)->b6;
[test4.c:11:7] q_3 = [test4.c:11:11] &[test4.c:11:17] pb4_b6_1(D)->b4;
[test4.c:12:9] d_4 = MAX_EXPR ;
[test4.c:14:8] MEM [(char *)d_4 + 3B] = { 0, 0, 0, 0 };
[test4.c:18:1] return;
}
It looks like a false negative for -Wstringop-overflow=
[Bug target/102483] Reduction of 4 chars can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102483
--- Comment #5 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:73c535a00bc4dfe9a939cd80facbe79a929cab3e
commit r12-4339-g73c535a00bc4dfe9a939cd80facbe79a929cab3e
Author: liuhongt
Date: Sat Oct 9 14:34:38 2021 +0800
Support reduc_{plus,smax,smin,umax,umin}_scal_v4qi.
gcc/ChangeLog
PR target/102483
* config/i386/i386-expand.c (emit_reduc_half): Handle
V4QImode.
* config/i386/mmx.md (reduc__scal_v4qi): New expander.
(reduc_plus_scal_v4qi): Ditto.
gcc/testsuite/ChangeLog
* gcc.target/i386/pr102483.c: New test.
* gcc.target/i386/pr102483-2.c: New test.
[Bug libgomp/102628] [12 regression] New test case libgomp.c-c++-common/alloc-9.c fails after its introduction in r12-4033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102628
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:342aedf0e5f324cc2fb026466a8cc5cc7f839183
commit r12-4341-g342aedf0e5f324cc2fb026466a8cc5cc7f839183
Author: Jakub Jelinek
Date: Tue Oct 12 09:30:41 2021 +0200
libgomp: alloc* test fixes [PR102628, PR102668]
As reported, the alloc-9.c test and alloc-{1,2,3}.F* and alloc-11.f90
tests fail on powerpc64-linux with -m32.
The reason why it fails just there is that malloc doesn't guarantee there
128-bit alignment (historically glibc guaranteed 2 * sizeof (void *)
alignment from malloc).
There are two separate issues.
One is a thinko on my side.
In this part of alloc-9.c test (copied to alloc-11.f90), we have
2 allocators, a with pool size 1024B and alignment 16B and default fallback
and a2 with pool size 512B and alignment 32B and a as fallback allocator.
We start at no allocations in both at line 194 and do:
p = (int *) omp_alloc (sizeof (int), a2);
// This succeeds in a2 and needs 4+overhead bytes (which includes the 32B
alignment)
p = (int *) omp_realloc (p, 420, a, a2);
// This allocates 420 bytes+overhead in a, with 16B alignment and
deallocates the above
q = (int *) omp_alloc (sizeof (int), a);
// This allocates 4+overhead bytes in a, with 16B alignment
q = (int *) omp_realloc (q, 420, a2, a);
// This allocates 420+overhead in a2 with 32B alignment
q = (int *) omp_realloc (q, 768, a2, a2);
// This attempts to reallocate, but as there are elevated alignment
// requirements doesn't try to just realloc (even if it wanted to try that
// a2 is almost full, with 512-420-overhead bytes left in it), so it
// tries to alloc in a2, but there is no space left in the pool, falls
// back to a, which already has 420+overhead bytes allocated in it and
// 1024-420-overhead bytes left and so fails too and fails to default
// non-pool allocator that allocates it, but doesn't guarantee alignment
// higher than malloc guarantees.
// But, the test expected 16B alignment.
So, I've slightly lowered the allocation sizes in that part of the test
420->320 and 768 -> 568, so that the last test still fails to allocate
in a2 (568 > 512-320-overhead) but succeeds in a as fallback, which was
the intent of the test.
Another thing is that alloc-1.F90 seems to be transcription of
libgomp.c-c++-common/alloc-1.c into Fortran, but alloc-1.c had:
q = (int *) omp_alloc (768, a2);
if uintptr_t) q) % 16) != 0)
abort ();
q[0] = 7;
q[767 / sizeof (int)] = 8;
r = (int *) omp_alloc (512, a2);
if uintptr_t) r) % __alignof (int)) != 0)
abort ();
there but Fortran has:
cq = omp_alloc (768_c_size_t, a2)
if (mod (transfer (cq, intptr), 16_c_intptr_t) /= 0) stop 12
call c_f_pointer (cq, q, [768 / c_sizeof (i)])
q(1) = 7
q(768 / c_sizeof (i)) = 8
cr = omp_alloc (512_c_size_t, a2)
if (mod (transfer (cr, intptr), 16_c_intptr_t) /= 0) stop 13
I'm changing the latter to 4_c_intptr_t because other spots in the
testcase do that, Fortran sadly doesn't have c_alignof, but strictly
speaking it isn't correct, __alignof (int) could be on some architectures
smaller than 4.
So probably alloc-1.F90 etc. should also have
! { dg-additional-sources alloc-7.c }
! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is
valid for Fortran but not for C" }
and use get__alignof_int.
2021-10-12 Jakub Jelinek
PR libgomp/102628
PR libgomp/102668
* testsuite/libgomp.c-c++-common/alloc-9.c (main): Decrease
allocation sizes from 420 to 320 and from 768 to 568.
* testsuite/libgomp.fortran/alloc-11.f90: Likewise.
* testsuite/libgomp.fortran/alloc-1.F90: Change expected alignment
for cr from 16 to 4.
[Bug libgomp/102668] [12 regression] several libgomp alloc test case failures after r12-3976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102668
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:342aedf0e5f324cc2fb026466a8cc5cc7f839183
commit r12-4341-g342aedf0e5f324cc2fb026466a8cc5cc7f839183
Author: Jakub Jelinek
Date: Tue Oct 12 09:30:41 2021 +0200
libgomp: alloc* test fixes [PR102628, PR102668]
As reported, the alloc-9.c test and alloc-{1,2,3}.F* and alloc-11.f90
tests fail on powerpc64-linux with -m32.
The reason why it fails just there is that malloc doesn't guarantee there
128-bit alignment (historically glibc guaranteed 2 * sizeof (void *)
alignment from malloc).
There are two separate issues.
One is a thinko on my side.
In this part of alloc-9.c test (copied to alloc-11.f90), we have
2 allocators, a with pool size 1024B and alignment 16B and default fallback
and a2 with pool size 512B and alignment 32B and a as fallback allocator.
We start at no allocations in both at line 194 and do:
p = (int *) omp_alloc (sizeof (int), a2);
// This succeeds in a2 and needs 4+overhead bytes (which includes the 32B
alignment)
p = (int *) omp_realloc (p, 420, a, a2);
// This allocates 420 bytes+overhead in a, with 16B alignment and
deallocates the above
q = (int *) omp_alloc (sizeof (int), a);
// This allocates 4+overhead bytes in a, with 16B alignment
q = (int *) omp_realloc (q, 420, a2, a);
// This allocates 420+overhead in a2 with 32B alignment
q = (int *) omp_realloc (q, 768, a2, a2);
// This attempts to reallocate, but as there are elevated alignment
// requirements doesn't try to just realloc (even if it wanted to try that
// a2 is almost full, with 512-420-overhead bytes left in it), so it
// tries to alloc in a2, but there is no space left in the pool, falls
// back to a, which already has 420+overhead bytes allocated in it and
// 1024-420-overhead bytes left and so fails too and fails to default
// non-pool allocator that allocates it, but doesn't guarantee alignment
// higher than malloc guarantees.
// But, the test expected 16B alignment.
So, I've slightly lowered the allocation sizes in that part of the test
420->320 and 768 -> 568, so that the last test still fails to allocate
in a2 (568 > 512-320-overhead) but succeeds in a as fallback, which was
the intent of the test.
Another thing is that alloc-1.F90 seems to be transcription of
libgomp.c-c++-common/alloc-1.c into Fortran, but alloc-1.c had:
q = (int *) omp_alloc (768, a2);
if uintptr_t) q) % 16) != 0)
abort ();
q[0] = 7;
q[767 / sizeof (int)] = 8;
r = (int *) omp_alloc (512, a2);
if uintptr_t) r) % __alignof (int)) != 0)
abort ();
there but Fortran has:
cq = omp_alloc (768_c_size_t, a2)
if (mod (transfer (cq, intptr), 16_c_intptr_t) /= 0) stop 12
call c_f_pointer (cq, q, [768 / c_sizeof (i)])
q(1) = 7
q(768 / c_sizeof (i)) = 8
cr = omp_alloc (512_c_size_t, a2)
if (mod (transfer (cr, intptr), 16_c_intptr_t) /= 0) stop 13
I'm changing the latter to 4_c_intptr_t because other spots in the
testcase do that, Fortran sadly doesn't have c_alignof, but strictly
speaking it isn't correct, __alignof (int) could be on some architectures
smaller than 4.
So probably alloc-1.F90 etc. should also have
! { dg-additional-sources alloc-7.c }
! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is
valid for Fortran but not for C" }
and use get__alignof_int.
2021-10-12 Jakub Jelinek
PR libgomp/102628
PR libgomp/102668
* testsuite/libgomp.c-c++-common/alloc-9.c (main): Decrease
allocation sizes from 420 to 320 and from 768 to 568.
* testsuite/libgomp.fortran/alloc-11.f90: Likewise.
* testsuite/libgomp.fortran/alloc-1.F90: Change expected alignment
for cr from 16 to 4.
[Bug libgomp/102668] [12 regression] several libgomp alloc test case failures after r12-3976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102668 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- Should be hopefully fixed now.
[Bug libgomp/102628] [12 regression] New test case libgomp.c-c++-common/alloc-9.c fails after its introduction in r12-4033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102628 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Should be hopefully fixed now.
[Bug pch/45471] ICE with PCH and differening strict-aliasing settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45471 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Fixed a different way than my patch. It was fixed by r6-5494 where get_alias_set no longer depends on strict-aliasing. This was done to fix the attribute option fno-strict-aliasing (or fstrict-aliasing) case for functions.
[Bug middle-end/102700] New: [Diagnostics] uninitialized warning missing after O2 vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102700
Bug ID: 102700
Summary: [Diagnostics] uninitialized warning missing after O2
vectorization.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
testcase is from g++.dg/warn/Wuninitialized-13.C
struct shared_count {
shared_count () { }
shared_count (shared_count &r)
: pi (r.pi) { } // { dg-warning "\\\[-Wuninitialized" "" { xfail {
i?86-*-* x86_64-*-* } } }
int pi;
};
// There's another (redundant) -Wuninitialized on the line below.
struct shared_ptr {
int ptr;
shared_count refcount;
};
struct Bar {
Bar (int, shared_ptr);
};
void g () {
shared_ptr foo;
Bar (0, foo);
}
After vectorization
.C.211.uninit1
;; Function g (_Z1gv, funcdef_no=6, decl_uid=4497, cgraph_uid=13,
symbol_order=12)
void g ()
{
int * vectp.11;
vector(2) int * vectp.10;
vector(2) int vect__6.9;
int * vectp.8;
vector(2) int * vectp_foo.7;
struct shared_ptr foo;
struct shared_ptr D.4566;
struct Bar D.4567;
[local count: 1073741824]:
[test2.C:6:19] MEM[(struct shared_count *)[test2.C:23:14] &foo + 4B] ={v}
{CLOBBER};
[test2.C:13:8] vect__6.9_12 = MEM [(int *)&foo];
[test2.C:8:5] MEM[(struct shared_count *)[test2.C:24:3] &D.4566 + 4B] ={v}
{CLOBBER};
[test2.C:13:8] MEM [(int *)&D.4566] = vect__6.9_12;
[test2.C:24:3] Bar::Bar ([test2.C:24:3] &D.4567, 0, [test2.C:24:3] &D.4566);
[test2.C:24:3] D.4567 ={v} {CLOBBER};
[test2.C:24:3] D.4566 ={v} {CLOBBER};
foo ={v} {CLOBBER};
[test2.C:25:1] return;
}
MEM [(int *)&foo]; is used instead of _6 = foo.ptr; which is
missed by warn_uninitialized_vars?
[Bug middle-end/102700] [Diagnostics] uninitialized warning missing after O2 vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102700 --- Comment #1 from Hongtao.liu --- Maybe i should i -fno-tree-vectorize to this testcase.
[Bug fortran/102541] [12 Regression] runtime error: load of value 208393040, which is not a valid value for type 'ar_type' since r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102541 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:eb92cd57a1ebe7cd7589bdbec34d9ae337752ead commit r12-4346-geb92cd57a1ebe7cd7589bdbec34d9ae337752ead Author: Tobias Burnus Date: Tue Oct 12 09:56:08 2021 +0200 Fortran: Various CLASS + assumed-rank fixed [PR102541] Starting point was PR102541, were a previous patch caused an invalid e->ref access for class. When testing, it turned out that for CLASS to CLASS the code was never executed - additionally, issues appeared for optional and a bogus error for -fcheck=all. In particular: There were a bunch of issues related to optional CLASS, can have the 'attr.dummy' set in CLASS_DATA (sym) - but sometimes also in 'sym'!?! Additionally, gfc_variable_attr could return pointer = 1 for nonpointers when the expr is no longer "var" but "var%_data". PR fortran/102541 gcc/fortran/ChangeLog: * check.c (gfc_check_present): Handle optional CLASS. * interface.c (gfc_compare_actual_formal): Likewise. * trans-array.c (gfc_trans_g77_array): Likewise. * trans-decl.c (gfc_build_dummy_array_decl): Likewise. * trans-types.c (gfc_sym_type): Likewise. * primary.c (gfc_variable_attr): Fixes for dummy and pointer when 'class%_data' is passed. * trans-expr.c (set_dtype_for_unallocated, gfc_conv_procedure_call): For assumed-rank dummy, fix setting rank for dealloc/notassoc actual and setting ubound to -1 for assumed-size actuals. gcc/testsuite/ChangeLog: * gfortran.dg/assumed_rank_24.f90: New test.
[Bug target/102688] [12 regression] gcc.dg/ipa/iinline-attr.c fails after r12-4288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102688
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #2 from Martin Liška ---
Yes, it's turned off by default in rs6000 here:
static const struct default_options rs6000_option_optimization_table[] =
{
...
/* -frename-registers leads to non-optimal codegen and performance
on rs6000, turn it off by default. */
{ OPT_LEVELS_ALL, OPT_frename_registers, NULL, 0 },
...
}
I'm going to handle it.
[Bug middle-end/80375] [5/6 Regression] ICE in expand_expr_real_2, at expr.c:9382 with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80375 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |7.0
[Bug target/45683] Segmentation fault on large unsigned integer values in C99 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45683 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed for GCC 7 by r7-7666.
[Bug target/45683] Segmentation fault on large unsigned integer values in C99 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45683 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #6 from Andrew Pinski --- .
[Bug fortran/102698] omp atomic capture Abnormal results after running multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102698 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- Your testcase is racy and therefore anything can happen. Please see https://www.openmp.org/spec-html/5.1/openmpsu105.html#x138-1480002.19.7 "Only the read and write of the location designated by x are performed mutually atomically. Neither the evaluation of expr or expr-list, nor the write to the location designated by v, need be atomic with respect to the read or write of the location designated by x." But the testcase is expecting that the store to o(idx(i), idy(i)) will be atomic and done whenever the atomic or succeeds. That is not the case, the store is done after the atomic or succeeded, but using a normal store instruction and other threads can store the same location in between (e.g. even though they performed the atomic instruction later, they can store the result earlier).
[Bug fortran/102701] New: CLASS (polymorphism) + symbol/expression attribute – wrong attribute status (audit task)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102701
Bug ID: 102701
Summary: CLASS (polymorphism) + symbol/expression attribute –
wrong attribute status (audit task)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
In patch https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580624.html (*)
I fixed a couple of issues, but I think there are more related to attributes
and CLASS.
(*) committed as r12-4346-geb92cd57a1ebe7cd7589bdbec34d9ae337752ead / PR102541.
In gfc_variable_attr itself:
optional = attr.optional;
if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived)
optional |= CLASS_DATA (sym)->attr.optional;
But at least when queried from trans*.c, the 'var' has been modified to
'var%_data'. Thus, this attribute may not be overwritten in the
'ref->component' loop for '_data'.
I am also not sure whether attr.dummy is properly handled in gfc_variable_attr
or other attributes.
I do see some explicit code in trans*.c, which might or might not need to be
updated:
if (sym->attr.allocatable)
{
if (sym->attr.dummy || sym->attr.result)
For the first point, maybe something like:
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index d873264a08e..49d56ec5d44 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2710,3 +2710,2 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
comp = ref->u.c.component;
- attr = comp->attr;
if (ts != NULL && !has_inquiry_part)
@@ -2723,2 +2722,3 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
{
+ attr = comp->attr;
codimension = CLASS_DATA (comp)->attr.codimension;
@@ -2726,2 +2726,3 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
allocatable = CLASS_DATA (comp)->attr.allocatable;
+ optional = false;
}
@@ -2733,4 +2734,7 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
else
- pointer = comp->attr.pointer;
- allocatable = comp->attr.allocatable;
+ {
+ attr = comp->attr;
+ pointer = comp->attr.pointer;
+ optional = false;
+ }
}
might be useful – but some careful checking of other attributes should be done.
[Bug fortran/102541] [12 Regression] runtime error: load of value 208393040, which is not a valid value for type 'ar_type' since r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102541 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Tobias Burnus --- FIXED! Thanks for the UBSAN run. A follow-up PR102701 has been opened regarding some more CLASS corner cases (unrelated to this PR / the original bug, but related to issues found when fixing it.)
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 102541, which changed state. Bug 102541 Summary: [12 Regression] runtime error: load of value 208393040, which is not a valid value for type 'ar_type' since r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102541 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/102698] omp atomic capture Abnormal results after running multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102698 --- Comment #3 from Jakub Jelinek --- Just one extra note: !$omp atomic capture x(idx(i), idy(i)) = ior(x(idx(i), idy(i)), fun(i)) o(idx(i), idy(i)) = x(idx(i), idy(i)) !$omp end atomic is really (under the hood): temp_expr = fun(i) !$omp atomic capture x(idx(i), idy(i)) = ior(x(idx(i), idy(i)), temp_expr) temp_v = x(idx(i), idy(i)) !$omp end atomic o(idx(i), idy(i)) = temp_v and if you write it that way, it is more obvious your program is racy. Even the x(idx(i), idy(i)) expression gets its address evaluated once before the construct (if it has some side-effects) and then it is just __atomic_or_fetch on that address.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 --- Comment #8 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:a1a7d094307080c3d994209457f732005f59fa6a commit r12-4348-ga1a7d094307080c3d994209457f732005f59fa6a Author: Eric Botcazou Date: Tue Oct 12 11:20:42 2021 +0200 Fix PR target/102588 We need a 32-byte wide integer mode (OImode) in order to handle structure returns in the 64-bit ABI. gcc/ PR target/102588 * config/sparc/sparc-modes.def (OI): New integer mode.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1cedb519613006014eeb1a7464a5fbc3509a3a63 commit r11-9098-g1cedb519613006014eeb1a7464a5fbc3509a3a63 Author: Eric Botcazou Date: Tue Oct 12 11:20:42 2021 +0200 Fix PR target/102588 We need a 32-byte wide integer mode (OImode) in order to handle structure returns in the 64-bit ABI. gcc/ PR target/102588 * config/sparc/sparc-modes.def (OI): New integer mode.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:bde91c72cb2cc47cd169d2a59470177dd7a1d2b9 commit r10-10180-gbde91c72cb2cc47cd169d2a59470177dd7a1d2b9 Author: Eric Botcazou Date: Tue Oct 12 11:20:42 2021 +0200 Fix PR target/102588 We need a 32-byte wide integer mode (OImode) in order to handle structure returns in the 64-bit ABI. gcc/ PR target/102588 * config/sparc/sparc-modes.def (OI): New integer mode.
[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102588 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.4 Status|ASSIGNED|RESOLVED --- Comment #11 from Eric Botcazou --- .
[Bug fortran/54322] [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54322
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #2 from Tobias Burnus ---
The problem is:
copy_ts_from_selector_to_associate (gfc_expr *associate, gfc_expr *selector)
which has:
if (selector->ts.type == BT_CLASS)
{
/* The correct class container has to be available. */
assoc_sym->ts.type = BT_CLASS;
assoc_sym->ts.u.derived = CLASS_DATA (selector)
? CLASS_DATA (selector)->ts.u.derived : selector->ts.u.derived;
assoc_sym->attr.pointer = 1;
gfc_build_class_symbol (&assoc_sym->ts, &assoc_sym->attr,
&assoc_sym->as);
}
The latter sets pointer = 1 – such that 'AN' wrongly has the pointer attribute
but it does not have the allocate attribute.
Thus, also:
select type ( AN => pc_alloc )
class is ( POINT )
if (.not. allocated (an)) error stop
fails.
[Bug c++/102496] [11 regression] extern __thread and thread_local declaration in function scope produces a non-TLS reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102496 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 11.3+.
[Bug libstdc++/102667] Inconsistent result of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2560bab6ceb7c1eb7c5cdadb5f0a608ac166b829 commit r11-9099-g2560bab6ceb7c1eb7c5cdadb5f0a608ac166b829 Author: Jonathan Wakely Date: Mon Oct 11 09:07:15 2021 +0100 libstdc++: Fix std::match_results::end() for failed matches [PR102667] The end() function needs to consider whether the underlying vector is empty, not whether the match_results object is empty. That's because the underlying vector will always contain at least three elements for a match_results object that is "ready". It contains three extra elements which are stored in the vector but are not considered part of sequence, and so should not be part of the [begin(),end()) range. libstdc++-v3/ChangeLog: PR libstdc++/102667 * include/bits/regex.h (match_result::empty()): Optimize by calling the base function directly. (match_results::end()): Check _Base_type::empty() not empty(). * testsuite/28_regex/match_results/102667.C: New test. (cherry picked from commit 84088dc4bb6a546c896a068dc201463493babf43)
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:95d404d85c53e4ab821ac28cbbbedf0d68cac8da commit r11-9102-g95d404d85c53e4ab821ac28cbbbedf0d68cac8da Author: Jonathan Wakely Date: Wed Sep 15 21:49:29 2021 +0100 libstdc++: Add missing constraint to std::span deduction guide [PR102280] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102280 * include/std/span (span(Range&&)): Add constraint to deduction guide. (cherry picked from commit e67917f5df9d84f5aed3513b3931a82870d25135)
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:63d91069ba8a9f1dc8bfa56ebfc10903a999f1cb commit r11-9104-g63d91069ba8a9f1dc8bfa56ebfc10903a999f1cb Author: Jonathan Wakely Date: Wed Sep 15 21:53:35 2021 +0100 libstdc++: Add missing 'constexpr' to std::tuple [PR102270] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102270 * include/std/tuple (_Head_base, _Tuple_impl): Add _GLIBCXX20_CONSTEXPR to allocator-extended constructors. (tuple<>::swap(tuple&)): Add _GLIBCXX20_CONSTEXPR. * testsuite/20_util/tuple/cons/102270.C: New test. (cherry picked from commit 734b2c2eedca50d966e22540fc136158c3633393)
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9c2eea2841aa2ca165b9055763fffcee5008bf83 commit r11-9105-g9c2eea2841aa2ca165b9055763fffcee5008bf83 Author: Jonathan Wakely Date: Fri Sep 17 12:27:02 2021 +0100 libstdc++: Fix last std::tuple constructor missing 'constexpr' [PR102270] Also rename the test so it actually runs. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102270 * include/std/tuple (_Tuple_impl): Add constexpr to constructor missed in previous patch. * testsuite/20_util/tuple/cons/102270.C: Moved to... * testsuite/20_util/tuple/cons/102270.cc: ...here. * testsuite/util/testsuite_allocator.h (SimpleAllocator): Add constexpr to constructor so it can be used for C++20 tests. (cherry picked from commit 1fa2c5a695bb962ffcf8abed49f69cdcc59d0e61)
[Bug libstdc++/102074] include/bits/atomic_timed_wait.h:215: possible missing return ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:aeee9251c64fe59c3e548e843f08bbda302cb08b commit r11-9106-gaeee9251c64fe59c3e548e843f08bbda302cb08b Author: Jonathan Wakely Date: Tue Aug 31 16:50:17 2021 +0100 libstdc++: Add missing return for atomic timed wait [PR102074] This adds a missing return statement to the non-futex wait-until operation. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102074 * include/bits/atomic_timed_wait.h (__timed_waiter_pool) [!_GLIBCXX_HAVE_PLATFORM_TIMED_WAIT]: Add missing return. (cherry picked from commit 763eb1f19239ebb19c0f87590a4f02300c02c52b)
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7df66a0c95a6b3678c73385969c1395a8aab2bd6 commit r11-9107-g7df66a0c95a6b3678c73385969c1395a8aab2bd6 Author: Jonathan Wakely Date: Fri Aug 27 10:59:54 2021 +0100 libstdc++: Fix inefficiency in filesystem::absolute [PR99876] When the path is already absolute, the call to current_path() is wasteful, because operator/ will ignore the left operand anyway. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/99876 * src/c++17/fs_ops.cc (fs::absolute): Call non-throwing form, to avoid unnecessary current_path() call. (cherry picked from commit 07b990ee23e0c7a92d362dbb25fd5d57d95eb8be)
[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:90a4981e0951687056ec4735cfd3043b35a23502 commit r11-9109-g90a4981e0951687056ec4735cfd3043b35a23502 Author: Thomas Rodgers Date: Thu Sep 16 14:42:58 2021 -0700 libstdc++: Fix UB in atomic_ref/wait_notify.cc [PR101761] Remove UB in atomic_ref/wait_notify test. Signed-off-by: Thomas Rodgers libstdc++-v3/ChangeLog: PR libstdc++/101761 * testsuite/29_atomics/atomic_ref/wait_notify.cc (test): Use va and vb as arguments to wait/notify, remove unused bb local. (cherry picked from commit f9f1a6efaaeeec06d5c07378734cb8eb47b976a7)
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:da206878f64ef66b1f7527c4d87e8baf9a5c5bfd commit r11-9110-gda206878f64ef66b1f7527c4d87e8baf9a5c5bfd Author: Jonathan Wakely Date: Wed Sep 22 11:58:20 2021 +0100 libstdc++: std::system_category should know meaning of zero [PR102425] Although 0 is not an errno value, it should still be recognized as corresponding to a value belonging to the generic_category(). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102425 * src/c++11/system_error.cc (system_error_category::default_error_condition): Add 0 to switch. * testsuite/19_diagnostics/error_category/102425.cc: New test. (cherry picked from commit ce01e2e64c340dadb55a8a24c545a13e654804d4)
[Bug tree-optimization/101923] std::function's move ctor is slower than the copy one for empty source objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101923 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:73b0f810a17a5f529fc8342a2df31276d3538851 commit r11-9111-g73b0f810a17a5f529fc8342a2df31276d3538851 Author: Jonathan Wakely Date: Tue Aug 17 11:30:56 2021 +0100 libstdc++: Optimize std::function move constructor [PR101923] PR 101923 points out that the unconditional swap in the std::function move constructor makes it slower than copying an empty std::function. The copy constructor has to check for the empty case before doing anything, and that makes it very fast for the empty case. Adding the same check to the move constructor avoids copying the _Any_data POD when we don't need to. We can also inline the effects of swap, by copying each member and then zeroing the pointer members. This makes moving an empty object at least as fast as copying an empty object. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101923 * include/bits/std_function.h (function(function&&)): Check for non-empty parameter before doing any work. (cherry picked from commit 0808b0df9c4d31f4c362b9c85fb538b6aafcb517)
[Bug libstdc++/101870] std::lerp is missing Arithmetic overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101870 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:371e12a7fd0295251340eabae77dd060577054c3 commit r11-9113-g371e12a7fd0295251340eabae77dd060577054c3 Author: Jonathan Wakely Date: Thu Aug 12 17:35:25 2021 +0100 libstdc++: Add additional overload of std::lerp [PR101870] The [cmath.syn] p1 wording about additional overloads sufficient to handle any arithmetic types also applies to std::lerp. This adds a new overload of std::lerp that does the required promotions to support arguments of arbitrary arithmetic types. A new __promoted_t alias template is added, which the C++17 function templates std::hypot and std::lerp can use to avoid instantiating the __promote_3 class template. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101870 * include/c_global/cmath (hypot): Use __promoted_t. (lerp): Add new overload accepting any arithmetic types. * include/ext/type_traits.h (__promoted_t): New alias template. * testsuite/26_numerics/lerp.cc: Moved to... * testsuite/26_numerics/lerp/1.cc: ...here. * testsuite/26_numerics/lerp/constexpr.cc: New test. * testsuite/26_numerics/lerp/version.cc: New test. (cherry picked from commit 9017326e19fe278d5f62898cca4682b17f8e8e07)
[Bug libstdc++/101960] std::tuple with an array element is rejected as a named return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101960 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:00967465fe8093661a4d42356821eeb04170e09d commit r11-9116-g00967465fe8093661a4d42356821eeb04170e09d Author: Jonathan Wakely Date: Thu Aug 19 11:48:40 2021 +0100 libstdc++: Fix move construction of std::tuple with array elements [PR101960] An array member cannot be direct-initialized in a ctor-initializer-list, so use the base class' move constructor, which does the right thing for both arrays and non-arrays. This constructor could be defaulted, but that would make it trivial for some specializations, which would change the argument passing ABI. Do that for the versioned namespace only. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101960 * include/std/tuple (_Tuple_impl(_Tuple_impl&&)): Use base class' move constructor. Define as defaulted for versioned namespace. * testsuite/20_util/tuple/cons/101960.cc: New test. (cherry picked from commit 0187e0d7360f327f88d8b2294668669306ae4630)
[Bug c++/102535] __is_trivially_constructible rejects some trivial cases in aggregate initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102535 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7b4e6d75b18dbb52bf507dbfd4c8e694e476d2af commit r11-9120-g7b4e6d75b18dbb52bf507dbfd4c8e694e476d2af Author: Jonathan Wakely Date: Tue Oct 5 09:32:11 2021 +0100 libstdc++: Fix testcase for newly-implemented C++20 semantics [PR102535] libstdc++-v3/ChangeLog: PR c++/102535 * testsuite/20_util/is_trivially_constructible/value.cc: Adjust expected value for C++20. (cherry picked from commit 7646847df71e57edca5ec5b8c3c3dc4550dcb49d)
[Bug libstdc++/101870] std::lerp is missing Arithmetic overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101870 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.3 --- Comment #4 from Jonathan Wakely --- Fixed for 11.3
[Bug tree-optimization/102572] [11/12 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 since r11-3070-g783dc66f9ccb0019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572
--- Comment #5 from Richard Biener ---
The to be vectorized IL is
[local count: 118111600]:
# i_21 = PHI
_2 = (int) i_21;
_32 = &(*d_16(D))[_2];
_3 = .MASK_LOAD (_32, 32B, h_15(D));
_5 = _3 != 0;
_23 = _5 & h_15(D);
prephitmp_36 = _23 ? 1 : 0;
i.3_6 = (unsigned short) i_21;
_7 = i.3_6 + 1;
i_18 = (short int) _7;
if (i_18 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 105119324]:
goto ; [100.00%]
and the issue is that the mask is an invariant but we're just using
vect_get_vec_defs_for_operand and that does
if (dt == vect_constant_def || dt == vect_external_def)
{
tree stmt_vectype = STMT_VINFO_VECTYPE (stmt_vinfo);
tree vector_type;
if (vectype)
vector_type = vectype;
else if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
&& VECTOR_BOOLEAN_TYPE_P (stmt_vectype))
vector_type = truth_type_for (stmt_vectype);
but of course stmt_vectype is not a boolean type but V8SI.
[Bug fortran/102698] omp atomic capture Abnormal results after running multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102698 --- Comment #4 from han.wu --- Thank you very much for your prompt reply！ @Jakub Jelinek One thing I don't quite understand is that if we modify the test case as suggested as the extra note, then the value of temp_v may vary at each execution, then what is the occasion to use an atomic capture structure with 2 statements? Could you please give me an example of a practical usage of it?
[Bug fortran/102698] omp atomic capture Abnormal results after running multiple times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102698 --- Comment #5 from Jakub Jelinek --- !$omp atomic capture v = x x = ior(x, expr) !$omp end atomic etc. is conceptually similar to !$omp atomic load v = x !$omp end atomic !$omp atomic update x = ior(x, expr) !$omp end atomic except that the capture form is atomic even together, the v is really the value of x right before the successful atomic ior, while in the latter case some other thread could modify x in between those 2 atomic constructs. And similarly, the forms that have v = x at the end are similar to two atomics in the other order. There are many cases where it is useful, e.g. for the fetch before operation you atomically or some flag but then you want to perform some code in the current thread only if the flag wasn't set before, etc. Similarly for the fetch after the operation. It really depends on what the code wants to achieve. What your testcase does is not useful though, you basically want to have 2 arrays the same content, you can achieve that by copying the atomically changed array to the other one at the end of parallel region, or by doing the atomics on both arrays separately.
[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102685 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |output_constructor_regular_ |output_constructor_regular_ |field, at varasm.c:5514 |field, at varasm.c:5514 ||since ||r12-4278-g74ccca380cde5e79 --- Comment #4 from Martin Liška --- Btw. started with r12-4278-g74ccca380cde5e79.
[Bug tree-optimization/102572] [11/12 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 since r11-3070-g783dc66f9ccb0019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9f12a45ef147e563f099c24c293830727e8204cc commit r12-4350-g9f12a45ef147e563f099c24c293830727e8204cc Author: Richard Biener Date: Tue Oct 12 13:42:08 2021 +0200 tree-optimization/102572 - fix gathers with invariant mask This fixes the vector def gathering for invariant masks which failed to pass in the desired vector type resulting in a non-mask type to be generate. 2021-10-12 Richard Biener PR tree-optimization/102572 * tree-vect-stmts.c (vect_build_gather_load_calls): When gathering the vectorized defs for the mask pass in the desired mask vector type so invariants will be handled correctly. * g++.dg/vect/pr102572.cc: New testcase.
[Bug fortran/102686] [PDT] ICE in check_host_association, at fortran/resolve.c:6055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102686 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-12 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r8-3056-g5bab4c9631c478b7.
[Bug tree-optimization/102696] [12 Regression] ICE in vect_build_slp_tree, at tree-vect-slp.c:1551 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102696 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d1dcaa31453fa080a27938b064e53f02272d4aa1 commit r12-4351-gd1dcaa31453fa080a27938b064e53f02272d4aa1 Author: Richard Biener Date: Tue Oct 12 13:49:39 2021 +0200 tree-optimization/102696 - fix SLP discovery for failed BIT_FIELD_REF This fixes a forgotten adjustment of matches[] when we fail SLP discovery. 2021-10-12 Richard Biener PR tree-optimization/102696 * tree-vect-slp.c (vect_build_slp_tree_2): Properly mark the tree fatally failed when we reject a BIT_FIELD_REF. * g++.dg/vect/pr102696.cc: New testcase.
[Bug tree-optimization/102572] [11 Regression] ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835 since r11-3070-g783dc66f9ccb0019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572 Richard Biener changed: What|Removed |Added Known to work||12.0 Summary|[11/12 Regression] ICE for |[11 Regression] ICE for skx |skx in |in |vect_build_gather_load_call |vect_build_gather_load_call |s, at |s, at |tree-vect-stmts.c:2835 |tree-vect-stmts.c:2835 |since |since |r11-3070-g783dc66f9ccb0019 |r11-3070-g783dc66f9ccb0019 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/102696] [12 Regression] ICE in vect_build_slp_tree, at tree-vect-slp.c:1551 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102696 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed. The branch doesn't cache negative entries so the issue is not latent.
[Bug demangler/102702] New: libiberty: heap/stack buffer overflow when decoding user input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102702 Bug ID: 102702 Summary: libiberty: heap/stack buffer overflow when decoding user input Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: contact at lsferreira dot net Target Milestone: --- Heap/stack buffer overflow in the dlang_lname function in d-demangle.c in libiberty allows attackers to potentially cause a denial of service (segmentation fault or crash) via a crafted mangled symbol. Example of affected symbols "_D2FGWG4EQe", "_D4c?441_Qe_4DmD_i==UUUqU", "_D33dddQ_D2DVV_D33dddQDVVHHDQN188Qr" and "_D8ee2_Qe". A CVE was already assigned by Red Hat: CVE-2021-3826: libiberty: heap/stack buffer overflow in the dlang_lname function in d-demangle.c
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #8 from Richard Biener --- I would mostly expect less peeling for alignment being done (and thus slightly smaller code size with the issue fixed).
[Bug demangler/102702] libiberty: heap/stack buffer overflow when decoding user input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102702 --- Comment #1 from Luís Ferreira --- Submitted patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579985.html
[Bug c++/101480] [11 Regression] Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480 --- Comment #23 from Jonathan Wakely --- The first thing a delete expression does is invoke the destructor, after that there is no object anyway.
[Bug lto/102649] GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102649 --- Comment #3 from Martin Liška --- All right, so being in the described situation I would recommend the following steps: 1) please try bisecting GCC revisions and find the first on that fixed the issue in between version 9.x and 10.x release. That would tell us more. 2) You can experiment with -fno-lto, which you can use for a subset of object files (the rest will be built with LTO). Doing that, you will be able to isolate that to a minimal set of objects that need -flto in order to expose the issue. 3) You can use -fdump-tree-all for LTO linking step and you can investigate if the caller really calls the function with an argument being set to 0.
[Bug c++/101480] [11 Regression] Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #24 from Richard Biener ---
(In reply to Jonathan Wakely from comment #23)
> The first thing a delete expression does is invoke the destructor, after
> that there is no object anyway.
The situation where we avoid the escape only is also hard to exploit
since the caller would have to use the object after deletion.
But one can do sth like
static int *storage;
void operator delete (void *p)
{
storage = (int *)p;
}
int main()
{
int *p = new int;
*p = 1;
int q;
storage = &q;
q = 3;
delete p;
*storage = 2;
if (q != 3)
__builtin_abort ();
}
where we while we still cannot CSE q across the delete call because q
escapes (to 'storage'), we do elide the new/delete pair which then
causes a runfail. The critical point here is (as in the original example
in this PR) that the user of new/delete expects a specific implementation
detail of new/delete (here setting of 'storage' by delete, upthread
the requirement to setting 'flag').
The whole point of making sure the argument of the delete does not make
the storage pointed to it escape (and not used) is to be able to DSE
stores to it (see the affected g++.dg/cpp1y/new1.C testcase) and thus
to elide more new/delete pairs.
[Bug c++/102535] __is_trivially_constructible rejects some trivial cases in aggregate initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102535 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.3 Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 11.3/12
[Bug tree-optimization/102703] New: [12 Regression] Dead Code Elimination Regression at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
Bug ID: 102703
Summary: [12 Regression] Dead Code Elimination Regression at
-O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat test.c
void foo(void);
static int a, b;
static short c;
int main() {
for (; a; ++a) {
unsigned short d = a;
c = d >= 2 ? 0 : 2;
if (!(b | d) && d)
foo();
}
}
gcc-11.2.0 test.c -S -O3 -o /dev/stdout
main:
.LFB0:
.cfi_startproc
.L2:
movla(%rip), %eax
testl %eax, %eax
je .L12
incla(%rip)
jmp .L2
.L12:
ret
.cfi_endproc
gcc-trunk test.c -S -O3 -o /dev/stdout
main:
.LFB0:
.cfi_startproc
movla(%rip), %eax
testl %eax, %eax
je .L25
.p2align 4,,10
.p2align 3
.L24:
movzwl %ax, %edx
cmpw$1, %ax
jbe .L27
testl %edx, %edx
jne .L35
.L33:
subq$8, %rsp
.cfi_def_cfa_offset 16
.L4:
callfoo
movla(%rip), %eax
addl$1, %eax
movl%eax, a(%rip)
je .L36
.L2:
movzwl %ax, %edx
cmpw$1, %ax
jbe .L3
testl %edx, %edx
je .L4
addl$1, %eax
movl%eax, a(%rip)
jne .L2
.L36:
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L35:
addl$1, %eax
movl%eax, a(%rip)
jne .L24
.L25:
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L27:
testl %edx, %edx
jne .L30
testb $1, %al
jne .L33
.L30:
addl$1, %eax
movl%eax, a(%rip)
jmp .L24
.p2align 4,,10
.p2align 3
.L3:
.cfi_def_cfa_offset 16
testl %edx, %edx
jne .L6
testb $1, %al
jne .L4
.L6:
addl$1, %eax
movl%eax, a(%rip)
jmp .L2
.cfi_endproc
gcc-trunk -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211012 (experimental) (GCC)
Started with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2e96b5f14e4025691b57d2301d71aa6092ed44bc
(same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546)
[Bug c++/102704] New: NRVO for throw expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102704
Bug ID: 102704
Summary: NRVO for throw expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider this code:
struct mytype
{
mytype();
mytype(mytype const&);
mytype(mytype&&);
};
void test()
{
mytype e;
throw e;
}
Currently for function test() GCC generates the following sequence of calls
(pseudocode):
char e[sizeof(mytype)];
mytype_default_ctor(e);
p = __cxa_allocate_exception();
mytype_move_ctor(p, e);
__cxa_throw(p);
I believe a trick similar to NRVO for returns can be made here. When a variable
meets NRVO criteria, compiler can remove the local variable and replace it with
a storage allocated by __cxa_allocate_exception. Here what I believe can be
generated:
p = __cxa_allocate_exception();
mytype_default_ctor(p);
__cxa_throw(p);
[Bug c++/102691] rvalue reference overload in not preferred over lvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102691 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Dup of PR102283 (will respond there) *** This bug has been marked as a duplicate of bug 102283 ***
[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283 Patrick Palka changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #6 from Patrick Palka --- *** Bug 102691 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102705] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
Bug ID: 102705
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat test.c
void foo(void);
static int b;
static char c;
static short a(short d, short e) { return e == 0 || d && e == 1 ? 0 : d % e; }
int main() {
b = c = b >= 2 ? 0 : 1 >> b;
short f = a(0 >= 0 ^ c, 5);
if (f == c)
foo();
a(0, 9);
}
11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:
gcc-11.2.0 test.c -S -O3 -o /dev/stdout
main:
.LFB1:
.cfi_startproc
movlb(%rip), %ecx
movl$1, %eax
sarl%cl, %eax
movl%eax, %edx
xorl%eax, %eax
cmpl$2, %ecx
cmovl %edx, %eax
movsbl %al, %eax
movl%eax, b(%rip)
xorl%eax, %eax
ret
.cfi_endproc
gcc-trunk test.c -S -O3 -o /dev/stdout
main:
.LFB1:
.cfi_startproc
movlb(%rip), %ecx
cmpl$1, %ecx
jle .L2
xorl%ecx, %ecx
movl%ecx, b(%rip)
.L5:
xorl%eax, %eax
ret
.L2:
movl$1, %eax
sarl%cl, %eax
movl%eax, %edx
movl%eax, b(%rip)
xorl$1, %edx
movsbw %dl, %dx
cmpw%ax, %dx
jne .L5
pushq %rax
.cfi_def_cfa_offset 16
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
gcc-trunk -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211012 (experimental) (GCC)
It started with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=145bc41dae7c7bfa093d61e77346f98e6a595a0e
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 --- Comment #1 from Theodoros Theodoridis --- (11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot)
[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
--- Comment #7 from Patrick Palka ---
(In reply to Fedor Chelnokov from comment #0 in PR102691)
> This code is valid:
> ```
> struct Foo {};
> struct Bar {};
>
> constexpr int Baz(const Foo&) { return 0; }
> constexpr int Baz(Bar&&) { return 1; }
>
> int main()
> {
> static_assert( Baz({}) == 1 );
> }
> ```
> Here Baz(Bar&&) must be preferred according to [over.ics.rank]/(3.2), as
> Clang does.
But according to [over.ics.list]/8, isn't the conversion from {} to an
aggregate type a user-defined conversion sequence and not a standard conversion
sequence? And according to [over.ics.rank]/3.3, two such user-defined
conversion sequences to different types are incomparable.
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 Martin Liška changed: What|Removed |Added Summary|[12 Regression] Dead Code |[12 Regression] Dead Code |Elimination Regression at |Elimination Regression at |-O3 (trunk vs 11.2.0) |-O3 since ||r12-2591-g2e96b5f14e402569 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-12 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r12-2591-g2e96b5f14e402569.
[Bug tree-optimization/102705] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2637-g145bc41dae7c7bfa093d61e77346f98e6a595a0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-10-12 Summary|[12 Regression] Dead Code |[12 Regression] Dead Code |Elimination Regression at |Elimination Regression at |-O3 (trunk vs 11.2.0) |-O3 since ||r12-2637-g145bc41dae7c7bfa0 ||93d61e77346f98e6a595a0e Status|UNCONFIRMED |NEW
[Bug tree-optimization/102706] New: [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706 Bug ID: 102706 Summary: [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- More fallout from enabling auto-vectorization at -O2. gcc.dg/Warray-bonds-48.c is regressing on most (but not all) of the embedded targets. Just picking one semi-randomly, iq2000-elf: Running target iq2000-sim Using /usr/share/dejagnu/baseboards/iq2000-sim.exp as board description file for target. Using /usr/share/dejagnu/config/sim.exp as generic interface file for target. Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description file for target. Using /home/jlaw/jenkins/workspace/iq2000-elf/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/jlaw/jenkins/workspace/iq2000-elf/gcc/gcc/testsuite/gcc.dg/dg.exp ... FAIL: gcc.dg/Warray-bounds-48.c (test for excess errors) === gcc Summary === # of expected passes38 # of unexpected failures1 /home/jlaw/jenkins/workspace/iq2000-elf/iq2000-elf-obj/gcc/gcc/xgcc version 12.0.0 20211008 (experimental) (GCC) >From the log file we see: FAIL: gcc.dg/Warray-bounds-48.c (test for excess errors) Excess errors: /home/jlaw/jenkins/workspace/iq2000-elf/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:33:12: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=] /home/jlaw/jenkins/workspace/iq2000-elf/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:133:12: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=] My very cursory examination of the test tells me this is a bogus warning. In both cases we have allocated enough space to reference array index 0 and 1. You should be able to reproduce this with a cross compiler without needing a cross assembler, library, etc.
[Bug c++/102707] New: template coroutine generated code failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102707
Bug ID: 102707
Summary: template coroutine generated code failed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: netcan1996 at gmail dot com
Target Milestone: ---
code: https://godbolt.org/z/f591eaTja
```cpp
#include
#include
#include
#include
template
struct task {
struct promise_type;
using coro_handle = std::coroutine_handle;
auto operator co_await() && noexcept {
return std::suspend_always{};
}
struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept {
return std::suspend_always {};
}
void unhandled_exception() { std::terminate(); }
task get_return_object() noexcept {
return {coro_handle::from_promise(*this)};
}
template
void return_value(U &&result) noexcept {
result_ = std::forward(result);
}
R result_;
};
coro_handle handle_;
};
struct Dummy {};
template
task coro_depth_n(std::vector& result) {
result.push_back(N);
if constexpr (N > 0) {
co_await coro_depth_n(result);
result.push_back(N * 10);
}
co_return Dummy{};
}
void test() {
std::vector result;
auto t = coro_depth_n<4>(result);
}
```
compiled failed message:
: In instantiation of 'task coro_depth_n(std::vector&)
[with long unsigned int N = 4]':
:49:29: required from here
:44:5: internal compiler error: in tsubst_copy, at cp/pt.c:17314
44 | co_return Dummy{};
| ^
0x1ff4db9 internal_error(char const*, ...)
???:0
0x7d54cd fancy_abort(char const*, int, char const*)
???:0
0xa44627 instantiate_decl(tree_node*, bool, bool)
???:0
0xa8714b instantiate_pending_templates(int)
???:0
0x8ec779 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/102707] template coroutine generated code failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102707 --- Comment #1 from Net Can --- the code is compiled success in msvc
[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Sure, you can, but just note that it is conservative and fast, it will
> return true even for types that don't have any padding.
> But for double, _Complex double, int etc. it will quickly return false.
> I guess I should use it in c-omp.c too.
I saw you changed c-omp.c today, I am wondering whether it's better to also add
the following as a common utility routine to dimple-fold.[ch], then I can use
it when adding padding initializations for auto var:
/* Return true if TYPE contains any padding bits. */
bool
clear_padding_type_has_padding_p (tree type)
{
bool clear_padding = false;
if (BITS_PER_UNIT == 8
&& CHAR_BIT == 8
&& clear_padding_type_may_have_padding_p (type))
{
HOST_WIDE_INT sz = int_size_in_bytes (cmptype), i;
gcc_assert (sz > 0);
unsigned char *buf = XALLOCAVEC (unsigned char, sz);
memset (buf, ~0, sz);
clear_type_padding_in_mask (cmptype, buf);
for (i = 0; i < sz; i++)
if (buf[i] != (unsigned char) ~0)
{
clear_padding = true;
break;
}
}
return clear_padding;
}
[Bug fortran/102708] New: Improve ''array temporary was created for argument" diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708
Bug ID: 102708
Summary: Improve ''array temporary was created for argument"
diagnostic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The message is produced by gfc_conv_subref_array_arg when called with:
if (fsym && proc_name)
msg = xasprintf ("An array temporary was created for argument "
"'%s' of procedure '%s'", fsym->name, proc_name);
else
msg = xasprintf ("An array temporary was created");
obviously the message is clearer when fsym + proc_name is available. However,
in gfc_conv_procedure_call those aren't passed.
Probably, it would be useful to have additionally the name of the calling
procedure, e.g.
"An array temporary was created in procedure '%s' for argument '%s' of
procedure '%s'"
Note: I also use it in my gfc_conv_gfc_desc_to_cfi_desc (submitted but
unreviewed patch); thus that one should then also have the better diagnostic.
(It already has the %s of proc %s diagnostic.)
[Bug fortran/102699] Stream access input/output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102699 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to xin liu from comment #0) > > is it a bug or is there something wrong with my understanding? I think you may be tripped up by "12.3.3.4 Stream access" where one finds P. 213 While connected for formatted stream access, an external file has the following properties. * Some file storage units of the file can contain record markers; this imposes a record structure on the file in addition to its stream structure. There might or might not be a record marker at the end of the file. If there is no record marker at the end of the file, the final record is incomplete. Followed by "12.3.4.2 Advancing and nonadvancing input/output" P. 214 An advancing input/output statement always positions a record file after the last record read or written, unless there is an error condition. If I trim your program to program streamio implicit none open(10, file="123.txt", access="stream") write(10) '098765' write(10) '239345' write(10) '123789' write(10) '789509' write(10) '543210' close(10) end the resulting filesize for 123.txt is 30 bytes. If, instead, I use program streamio implicit none open(10, file="123.txt", form="formatted", access="stream") write(10, "(A6)") '098765' write(10, "(A6)") '239345' write(10, "(A6)") '123789' write(10, "(A6)") '789509' write(10, "(A6)") '543210' close(10) end the resulting filesize for 123.txt is 35 bytes. So, record markers are written into the file. You can probably verify this by using INQUIRE and POS= after the READs in your original code to see if the file is positioned at the start of a record.
[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> and if you have a variable that isn't addressable, you need to figure out
> what to do. I think it might be easiest not to clear anything, another
> option is to create a temporary, store the var value in there, clear padding
> and copy back, but in the end the padding bits will probably not stay
> cleared.
currently, we add __builtin_clear_padding call _AFTER_ every explicit
initialization of an auto variable:
var_decl = {init_constructor};
__builtin_clear_padding (&var_decl, 0B, 1);
the reason I added the call to EVERY auto variable that has explicit
initialization is, the folding of __builtin_clear_padding will automatically
turn this call to a NOP when there is no padding in the variable. So, I don't
need to check whether the variable has padding explicitly.
However, looks like that it's still better to check the type has padding or not
before adding the call to save some compilation time for unnecessary folding of
the call.
In addition to this, if the auto variable is not addressable and need padding
(for example, long double or complex long double), then must it be in a
register? if so, we can do the following for them:
var_decl = ZERO;
var_decl = {init_constructor};
i.e, use zero to initialize the whole variable BEFORE explicit fields
initialization.
for such solution, I need to check whether an auto variable is not addressable
in the beginning of the routine "gimplify_init_constructor", how to check for
this?
let me know your opinion on this solution.
[Bug c++/102709] New: ICE: in build_function_type, at tree.c:7304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102709
Bug ID: 102709
Summary: ICE: in build_function_type, at tree.c:7304
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
12 Regression:
template
struct S { S(T) {} };
int main() {
S([]{});
}
https://godbolt.org/z/rM5Eo1rhh
[Bug c++/102710] New: ICE: in build_function_type, at tree.c:7304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102710
Bug ID: 102710
Summary: ICE: in build_function_type, at tree.c:7304
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
12 Regression:
template
struct S { S(T) {} };
int main() {
S([]{});
}
https://godbolt.org/z/rM5Eo1rhh
[Bug middle-end/102697] [12 Regression] overflow warning missing after -O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102697 Martin Sebor changed: What|Removed |Added Summary|[Diagnostics] overflow |[12 Regression] overflow |warning missing after O2|warning missing after -O2 |vectorization. |vectorization Last reconfirmed||2021-10-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Sebor --- Confirmed as a false negative and a GCC 12 regression. The expected warning is based on the assumption that an unknown offset to a subobject is non-negative. This assumption is supported by the constraint that pointer arithmetic must be confined to the [sub]object the pointer points to. I.e., it's not valid to form a pointer to one subobject by adding an offset to a pointer to another [sub]object (even within the same object). The same constraint is enforced by -Warray-bounds. The missing -Wstringop-overflow is due to the hack mentioned in the following discussion: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580172.html The warning is issued from the strlen pass which runs at -O2 and above. It's still issued when -fno-tree-vectorized is specified but should be issued even with vectorization, and ideally at all optimization levels, including -O0.
[Bug c/102711] New: Infinite loop with extern calls removed with -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102711
Bug ID: 102711
Summary: Infinite loop with extern calls removed with -O2 or
higher
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andy.koppe at analog dot com
Target Milestone: ---
Created attachment 51591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51591&action=edit
Minimized example
Compiling the minimised example below (and attached) with -O2 or higher, if
FAIL is defined, the second infinite loop is removed. Code is produced for it
when FAIL is not defined.
Reproduced with gcc 10.3.1 for aarch64-none-elf, gcc 11.2.0 for
x86_64-pc-cygwin, and gcc 9.3.0 for x86_64-linux-gnu.
$ cat test.c
int bar(void);
void foo(void)
{
if (!bar())
for (;;);
for (;;) {
static int flag = 0;
int ret = 0;
bar();
if (flag) {
ret = bar();
if (!ret)
ret = bar();
}
flag = !bar();
#ifdef FAIL
if (!ret)
#endif
bar();
}
}
$ aarch64-none-elf-gcc -O2 -S test.c -DFAIL
$ cat test.s
.arch armv8-a
.file "test.c"
.text
.align 2
.p2align 4,,11
.global foo
.type foo, %function
foo:
stp x29, x30, [sp, -16]!
mov x29, sp
bl bar
.L2:
b .L2
.size foo, .-foo
.ident "GCC: (GNU Toolchain for the A-profile Architecture
10.3-2021.07 (arm-10.29)) 10.3.1 20210621"
[Bug libstdc++/102181] std::advance and std::views::iota don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102181 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d9dfd7ad3e0196f60a3fc6df6d65a40fb905409f commit r12-4355-gd9dfd7ad3e0196f60a3fc6df6d65a40fb905409f Author: Jonathan Wakely Date: Wed Sep 29 21:19:36 2021 +0100 libstdc++: Improve diagnostics for misuses of output iterators This adds deleted overloads so that the errors for invalid uses of std::advance and std::distance are easier to understand (see for example PR 102181). libstdc++-v3/ChangeLog: * include/bits/stl_iterator_base_funcs.h (__advance): Add deleted overload to improve diagnostics. (__distance): Likewise.
[Bug libstdc++/101960] std::tuple with an array element is rejected as a named return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101960 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7481021364e75ba583972e15ed421a53988368ea commit r12-4356-g7481021364e75ba583972e15ed421a53988368ea Author: Jonathan Wakely Date: Tue Oct 12 15:09:50 2021 +0100 libstdc++: Fix move construction of std::tuple with array elements [PR101960] The r12-3022 commit only fixed the case where an array is the last element of the tuple. This fixes the other cases too. We can just define the move constructor as defaulted, which does the right thing. Changing the move constructor to be trivial would be an ABI break, but since the last base class still has a non-trivial move constructor, defining the derived ones as defaulted doesn't change anything. libstdc++-v3/ChangeLog: PR libstdc++/101960 * include/std/tuple (_Tuple_impl(_Tuple_impl&&)): Define as defauled. * testsuite/20_util/tuple/cons/101960.cc: Check tuples with array elements before the last element.
[Bug c++/102710] ICE: in build_function_type, at tree.c:7304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102710 康桓瑋 changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from 康桓瑋 --- Sorry for the network delay. *** This bug has been marked as a duplicate of bug 102709 ***
[Bug c++/102709] ICE: in build_function_type, at tree.c:7304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102709 --- Comment #1 from 康桓瑋 --- *** Bug 102710 has been marked as a duplicate of this bug. ***
[Bug libstdc++/102712] New: std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 Bug ID: 102712 Summary: std::optional::operator* should assert on unset value Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ott at fb dot com Target Milestone: --- It is UB to call operator* on an unset std::optional, and when doing so it is easy to hit time-traveling UB, resulting in behavior that is very hard to debug. For example, setting a field of an unset optional with operator-> may look like it succeeded, and the rest of the program will behave as if the optional was set, but it will silently leak memory because the destructor won't run. Another plausible scenario is having an optional where X has an operator bool(), and spelling "if (*opt)" when the intention is to spell "if (opt)". The program compiles and the optional is just assumed set around the condition. Even UBSan with some of the strictest settings doesn't detect this. All major implementations of the type have defined behavior in debug builds: - libc++ asserts https://github.com/llvm-mirror/libcxx/blob/master/include/optional#L905 - boost asserts https://github.com/boostorg/optional/blob/develop/include/boost/optional/optional.hpp#L1213 - abseil asserts https://github.com/abseil/abseil-cpp/blob/master/absl/types/optional.h#L428 - folly throws (in any compilation mode) https://github.com/facebook/folly/blob/master/folly/Optional.h#L330 https://github.com/facebook/folly/blob/master/folly/Optional.h#L297 So anyone migrating from any of these is in for a world of hurt. Please consider adding an assertion in libstdc++.
[Bug tree-optimization/102711] [9/10/11 Regression] CDDCE removes condition that might lead to an infinite loop causing an unconditional infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102711 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 --- Comment #1 from Andrew Pinski --- Looks to be fixed on the trunk.
[Bug libstdc++/102712] std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jonathan Wakely --- You mean like this one? /usr/include/c++/11/optional:440: constexpr _Tp& std::_Optional_base_impl<_Tp, _Dp>::_M_get() [with _Tp = int; _Dp = std::_Optional_base]: Assertion 'this->_M_is_engaged()' failed. Aborted (core dumped) It's been there since r248099 more than four years ago. Just compile with -D_GLIBCXX_ASSERTIONS
[Bug libstdc++/102712] std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Just compile with -D_GLIBCXX_ASSERTIONS Or the more heavyweight -D_GLIBCXX_DEBUG which implies _GLIBCXX_ASSERTIONS too.
[Bug tree-optimization/102711] [9/10/11 Regression] CDDCE removes condition that might lead to an infinite loop causing an unconditional infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102711
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-12
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Just for refence this is the testcase that can be done at runtime:
void exit(int);
__attribute__((noipa))
int bar(void)
{
static int t = 0;
t++;
if (t == 2) exit(0);
return 1;
}
__attribute__((noipa))
void foo(void)
{
if (!bar())
for (;;);
for (;;) {
static int flag = 0;
int ret = 0;
bar();
if (flag) {
ret = bar();
if (!ret)
ret = bar();
}
flag = !bar();
if (!ret)
bar();
}
}
int main(void)
{
foo();
}
[Bug libstdc++/102712] std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 --- Comment #3 from Giuseppe Ottaviano --- Oh well this is embarrassing, I was looking at _Optional_payload_base::_M_get() instead of _Optional_base_impl::_M_get() . Sorry for the noise and thanks for fixing this 4 years ago!
[Bug libstdc++/102181] [DR 3197] std::advance and std::views::iota don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102181 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Summary|std::advance and|[DR 3197] std::advance and |std::views::iota don't work |_t> don't work --- Comment #8 from Jonathan Wakely --- Suspending until https://wg21.link/lwg3197 is resolved.
[Bug c++/102709] [11/12 Regression] ICE: in build_function_type, at tree.c:7304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102709 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Known to work||10.3.0 Severity|normal |trivial Summary|ICE: in |[11/12 Regression] ICE: in |build_function_type, at |build_function_type, at |tree.c:7304 |tree.c:7304 Keywords||error-recovery, ||ice-on-invalid-code Known to fail||11.1.0 Status|UNCONFIRMED |NEW Target Milestone|--- |11.3 Last reconfirmed||2021-10-12 --- Comment #2 from Andrew Pinski --- >12 Regression: Not really: :6: confused by earlier errors, bailing out Well it is a regression from GCC 10 though.
[Bug target/99723] [11/12 Regression] arm: ICE in build_function_type during selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99723 Andrew Pinski changed: What|Removed |Added Summary|arm: ICE in |[11/12 Regression] arm: ICE |build_function_type during |in build_function_type |selftests |during selftests Target Milestone|--- |11.3
[Bug target/82524] [7/8 Regression] expensive-optimizations produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82524 --- Comment #21 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b37351e3279d192d5d4682f002abe5b2e133bba6 commit r12-4359-gb37351e3279d192d5d4682f002abe5b2e133bba6 Author: Uros Bizjak Date: Tue Oct 12 18:20:38 2021 +0200 i386: Improve workaround for PR82524 LRA limitation [PR85730] As explained in PR82524, LRA is not able to reload strict_low_part inout operand with matched input operand. The patch introduces a workaround, where we allow LRA to generate an instruction with non-matched input operand which is split post reload to an instruction that inserts non-matched input operand to an inout operand and the instruction that uses matched operand. The generated code improves from: movsbl %dil, %edx movl%edi, %eax sall$3, %edx movb%dl, %al to: movl%edi, %eax movb%dil, %al salb$3, %al which is still not optimal, but the code is one instruction shorter and does not use a temporary register. 2021-10-12 Uroš Bizjak gcc/ PR target/85730 PR target/82524 * config/i386/i386.md (*add_1_slp): Rewrite as define_insn_and_split pattern. Add alternative 1 and split it post reload to insert operand 1 into the low part of operand 0. (*sub_1_slp): Ditto. (*and_1_slp): Ditto. (*_1_slp): Ditto. (*ashl3_1_slp): Ditto. (*3_1_slp): Ditto. (*3_1_slp): Ditto. (*neg_1_slp): New insn_and_split pattern. (*one_cmpl_1_slp): Ditto. gcc/testsuite/ PR target/85730 PR target/82524 * gcc.target/i386/pr85730.c: New test.
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 --- Comment #10 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b37351e3279d192d5d4682f002abe5b2e133bba6 commit r12-4359-gb37351e3279d192d5d4682f002abe5b2e133bba6 Author: Uros Bizjak Date: Tue Oct 12 18:20:38 2021 +0200 i386: Improve workaround for PR82524 LRA limitation [PR85730] As explained in PR82524, LRA is not able to reload strict_low_part inout operand with matched input operand. The patch introduces a workaround, where we allow LRA to generate an instruction with non-matched input operand which is split post reload to an instruction that inserts non-matched input operand to an inout operand and the instruction that uses matched operand. The generated code improves from: movsbl %dil, %edx movl%edi, %eax sall$3, %edx movb%dl, %al to: movl%edi, %eax movb%dil, %al salb$3, %al which is still not optimal, but the code is one instruction shorter and does not use a temporary register. 2021-10-12 Uroš Bizjak gcc/ PR target/85730 PR target/82524 * config/i386/i386.md (*add_1_slp): Rewrite as define_insn_and_split pattern. Add alternative 1 and split it post reload to insert operand 1 into the low part of operand 0. (*sub_1_slp): Ditto. (*and_1_slp): Ditto. (*_1_slp): Ditto. (*ashl3_1_slp): Ditto. (*3_1_slp): Ditto. (*3_1_slp): Ditto. (*neg_1_slp): New insn_and_split pattern. (*one_cmpl_1_slp): Ditto. gcc/testsuite/ PR target/85730 PR target/82524 * gcc.target/i386/pr85730.c: New test.
[Bug libstdc++/101960] std::tuple with an array element is rejected as a named return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101960 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e748216c237cff2915390e9653de2db63b2161ac commit r11-9121-ge748216c237cff2915390e9653de2db63b2161ac Author: Jonathan Wakely Date: Tue Oct 12 15:09:50 2021 +0100 libstdc++: Fix move construction of std::tuple with array elements [PR101960] The r12-3022 commit only fixed the case where an array is the last element of the tuple. This fixes the other cases too. We can just define the move constructor as defaulted, which does the right thing. Changing the move constructor to be trivial would be an ABI break, but since the last base class still has a non-trivial move constructor, defining the derived ones as defaulted doesn't change anything. libstdc++-v3/ChangeLog: PR libstdc++/101960 * include/std/tuple (_Tuple_impl(_Tuple_impl&&)): Define as defauled. * testsuite/20_util/tuple/cons/101960.cc: Check tuples with array elements before the last element. (cherry picked from commit 7481021364e75ba583972e15ed421a53988368ea)
[Bug libstdc++/102667] Inconsistent result of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:be3fbe792444bc750a8a1b37481bac9a84528949 commit r10-10181-gbe3fbe792444bc750a8a1b37481bac9a84528949 Author: Jonathan Wakely Date: Mon Oct 11 09:07:15 2021 +0100 libstdc++: Fix std::match_results::end() for failed matches [PR102667] The end() function needs to consider whether the underlying vector is empty, not whether the match_results object is empty. That's because the underlying vector will always contain at least three elements for a match_results object that is "ready". It contains three extra elements which are stored in the vector but are not considered part of sequence, and so should not be part of the [begin(),end()) range. libstdc++-v3/ChangeLog: PR libstdc++/102667 * include/bits/regex.h (match_result::empty()): Optimize by calling the base function directly. (match_results::end()): Check _Base_type::empty() not empty(). * testsuite/28_regex/match_results/102667.C: New test. (cherry picked from commit 84088dc4bb6a546c896a068dc201463493babf43)
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1a27df25a71bb0d6a5dfb0162d1867d308f8f33f commit r10-10184-g1a27df25a71bb0d6a5dfb0162d1867d308f8f33f Author: Jonathan Wakely Date: Wed Sep 15 21:49:29 2021 +0100 libstdc++: Add missing constraint to std::span deduction guide [PR102280] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102280 * include/std/span (span(Range&&)): Add constraint to deduction guide. (cherry picked from commit e67917f5df9d84f5aed3513b3931a82870d25135)
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:154316697dbea9ba96bc14680b642b3ae35dadbd commit r10-10186-g154316697dbea9ba96bc14680b642b3ae35dadbd Author: Jonathan Wakely Date: Fri Aug 27 10:59:54 2021 +0100 libstdc++: Fix inefficiency in filesystem::absolute [PR99876] When the path is already absolute, the call to current_path() is wasteful, because operator/ will ignore the left operand anyway. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/99876 * src/c++17/fs_ops.cc (fs::absolute): Call non-throwing form, to avoid unnecessary current_path() call. (cherry picked from commit 07b990ee23e0c7a92d362dbb25fd5d57d95eb8be)
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:49f0936bdcdbad9903c3a1e9342205fd27cb8596 commit r10-10188-g49f0936bdcdbad9903c3a1e9342205fd27cb8596 Author: Jonathan Wakely Date: Wed Sep 22 11:58:20 2021 +0100 libstdc++: std::system_category should know meaning of zero [PR102425] Although 0 is not an errno value, it should still be recognized as corresponding to a value belonging to the generic_category(). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102425 * src/c++11/system_error.cc (system_error_category::default_error_condition): Add 0 to switch. * testsuite/19_diagnostics/error_category/102425.cc: New test. (cherry picked from commit ce01e2e64c340dadb55a8a24c545a13e654804d4)
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed for 10.4 and 11.3
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for 10.4 and 11.3 now.
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5 --- Comment #6 from Jonathan Wakely --- Fixed for 10.4 and 11.3 so far.
[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
Martin Sebor changed:
What|Removed |Added
CC||crazylht at gmail dot com
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Blocks||56456
Last reconfirmed||2021-10-12
--- Comment #1 from Martin Sebor ---
Confirmed. The root cause is similar as in the test case in pr102462 comment
4. Here, in addition to the expected -Warray-bounds (from the vrp1 pass) for
the invalid subscripts (before vectorization) the code also triggers
-Wstringop-overflow (from the strlen pass) for the two valid stores to p->ax at
indices 0 and 1 vectorized with the subsequent two stores. See the dumps
below.
Hongtao and I have been discussing the fallout of the autovectorization change
in the context of the following review:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581371.html
Hongtao, we could use this bug to track case (2) that you described in your
reply this morning in the thread above.
$ cat pr102706.c && /build/iq2000-elf/gcc-master/gcc/xgcc -B
/build/iq200f/gcc-master/gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout
-fdump-tree-strlen=/dev/stdout pr102706.c
typedef __INT16_TYPE__ int16_t;
typedef __INT32_TYPE__ int32_t;
void sink (void*);
/* Exercise a true flexible member. */
struct AX
{
int32_t n;
int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
};
static void warn_ax_local_buf (struct AX *p)
{
p->ax[0] = 4; p->ax[1] = 5;
p->ax[2] = 6; // { dg-warning "\\\[-Warray-bounds" }
p->ax[3] = 7; // { dg-warning "\\\[-Warray-bounds" }
p->ax[4] = 8; // { dg-warning "\\\[-Warray-bounds" }
}
void g (void)
{
/* Verify out-of-bounds access to the local BUF is diagnosed. */
char ax_buf_p2[sizeof (struct AX) + 2 * sizeof (int16_t)];
warn_ax_local_buf ((struct AX*) ax_buf_p2);
sink (ax_buf_p2);
}
;; Function g (g, funcdef_no=1, decl_uid=1438, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:18:8: warning: array subscript 2 is above array bounds of
'int16_t[]' {aka 'short int[]'} [-Warray-bounds]
18 | p->ax[2] = 6; // { dg-warning "\\\[-Warray-bounds" }
| ~^~~
pr102706.c: In function 'g':
pr102706.c:11:11: note: while referencing 'ax'
11 | int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
| ^~
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:19:8: warning: array subscript 3 is above array bounds of
'int16_t[]' {aka 'short int[]'} [-Warray-bounds]
19 | p->ax[3] = 7; // { dg-warning "\\\[-Warray-bounds" }
| ~^~~
pr102706.c: In function 'g':
pr102706.c:11:11: note: while referencing 'ax'
11 | int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
| ^~
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:20:8: warning: array subscript 4 is above array bounds of
'int16_t[]' {aka 'short int[]'} [-Warray-bounds]
20 | p->ax[4] = 8; // { dg-warning "\\\[-Warray-bounds" }
| ~^~~
pr102706.c: In function 'g':
pr102706.c:11:11: note: while referencing 'ax'
11 | int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
| ^~
void g ()
{
char ax_buf_p2[8];
[local count: 1073741824]:
MEM[(struct AX *)&ax_buf_p2].ax[0] = 4;
MEM[(struct AX *)&ax_buf_p2].ax[1] = 5;
MEM[(struct AX *)&ax_buf_p2].ax[2] = 6;
MEM[(struct AX *)&ax_buf_p2].ax[3] = 7;
MEM[(struct AX *)&ax_buf_p2].ax[4] = 8;
sink (&ax_buf_p2);
ax_buf_p2 ={v} {CLOBBER};
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1438, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:16:12: warning: writing 4 bytes into a region of size 0
[-Wstringop-overflow=]
16 | p->ax[0] = 4; p->ax[1] = 5;
| ~^~~
pr102706.c: In function 'g':
pr102706.c:27:8: note: at offset 8 into destination object 'ax_buf_p2' of size
8
27 | char ax_buf_p2[sizeof (struct AX) + 2 * sizeof (int16_t)];
|^
void g ()
{
int16_t * vectp.5;
vector(2) short int * vectp_ax_buf_p2.4;
char ax_buf_p2[8];
[local count: 1073741824]:
MEM [(short int *)&ax_buf_p2 + 4B] = { 4, 5 };
MEM [(short int *)&ax_buf_p2 + 8B] = { 6, 7 };
MEM[(struct AX *)&ax_buf_p2].ax[4] = 8;
sink (&ax_buf_p2);
ax_bu
