[Bug tree-optimization/95284] New: ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95284
Bug ID: 95284
Summary: ICE: verify_gimple failed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Reproducer:
#include
short a;
unsigned long long c;
char d;
unsigned e;
void f() {
for (;;)
for (char b = 0; b < 19; b += 2)
a = std::min((1 ? d : 0) ? e : c, (unsigned long long)72252803048);
}
Error:
>$ g++ -O3 func.cpp -c
func.cpp: In function ‘void f()’:
func.cpp:8:6: error: invalid ‘PHI’ argument
8 | void f() {
| ^
{CLOBBER}
_26 = PHI <72252803048(8), {CLOBBER}(5)>
during GIMPLE pass: sink
func.cpp:8:6: internal compiler error: verify_gimple failed
0x113fc71 verify_gimple_in_cfg(function*, bool)
gcc_src/gcc/tree-cfg.c:5461
0x10132af execute_function_todo
gcc_src/gcc/passes.c:1985
0x101408e execute_todo
gcc_src/gcc/passes.c:2039
GCC version:
11.0.0 (bcb63eb2cbd3caf212b9cf42d8c218c09dc6ff8b)
[Bug tree-optimization/95283] New: ICE: in hoist_memory_references, at tree-ssa-loop-im.c:2607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95283
Bug ID: 95283
Summary: ICE: in hoist_memory_references, at
tree-ssa-loop-im.c:2607
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Reproducer:
short c;
bool d;
unsigned e, f;
char g, h;
extern bool i[];
void j() {
for (char a = 0; a < 100; a++)
for (char b = 0; b < 20; b += 2) {
if (e)
d = f = 0;
else
g = i[8] = 0;
h = c;
}
}
Error:
>$ g++ -O3 func.cpp -c
during GIMPLE pass: lim
func.cpp: In function ‘void j()’:
func.cpp:6:6: internal compiler error: in hoist_memory_references, at
tree-ssa-loop-im.c:2607
6 | void j() {
| ^
0x822f8a hoist_memory_references
gcc_src/gcc/tree-ssa-loop-im.c:2607
0x822f8a store_motion_loop
gcc_src/gcc/tree-ssa-loop-im.c:2904
0x12381da do_store_motion
gcc_src/gcc/tree-ssa-loop-im.c:2929
0x12381da tree_ssa_lim
gcc_src/gcc/tree-ssa-loop-im.c:3148
0x12381da execute
gcc_src/gcc/tree-ssa-loop-im.c:3198
GCC version:
11.0.0 (bcb63eb2cbd3caf212b9cf42d8c218c09dc6ff8b)
[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 #2 from Andrew Pinski --- Can you show the code inside systemd (and the patch to fix it)? Because const void *p = (uint8_t*)0x406310; size_t s = -1; r = (uint8_t*)p + s; That is well defined.
[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 #1 from Andrew Pinski --- I don't see why this is undefined???
[Bug libstdc++/95282] New: atomic::load in C++20 calls __atomic_load with a pointer-to-const as the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95282
Bug ID: 95282
Summary: atomic::load in C++20 calls
__atomic_load with a pointer-to-const as the output
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
We have
_Fp
load(memory_order __m = memory_order_seq_cst) const noexcept
{ return __atomic_impl::load(&_M_fp, __m); }
which calls
template
_GLIBCXX_ALWAYS_INLINE _Tp
load(_Tp* __ptr, memory_order __m) noexcept
{
alignas(_Tp) unsigned char __buf[sizeof(_Tp)];
_Tp* __dest = reinterpret_cast<_Tp*>(__buf);
__atomic_load(__ptr, __dest, int(__m));
return *__dest;
}
Here &_M_fp is a const _Fp*, so _Tp is const-qualified. GCC's __atomic_load
appears to happily tolerate a pointer-to-const dest (which seems rather
dubious), but Clang's doesn't.
[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199 --- Comment #8 from Kaipeng Zhou --- (In reply to bin cheng from comment #7) > (In reply to rguent...@suse.de from comment #6) > > On Thu, 21 May 2020, zhoukaipeng3 at huawei dot com wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199 > > > > > > --- Comment #4 from Kaipeng Zhou --- > > > Sorry for not expressing clearly. > > > > > > I have debugged the testcase you provided. Not eliminating them is not > > > caused > > > by IFN. The relevant code is in the "get_computation_aff_1" function. > > > > > > In IVOPTs the IV_STEPs must be checked by function "constant_multiple_of" > > > before using an IV variable to eliminate the other. But if the tree_code > > > of > > > input IV_STEP is SSA_NAME, the function will return false. In your > > > testcase, > > > the tree_code of IV_STEP is MULT_EXPR, so it return true. > > > > > > Gimple for my testcase: > > >[local count: 8589933]: > > > _83 = (sizetype) inc_y_22(D); > > > _84 = _83 * POLY_INT_CST [16, 16]; > > > _85 = (long unsigned int) inc_y_22(D); > > > _86 = _85 * 8; > > > _87 = (ssizetype) _86; > > > _88 = _87 /[ex] 8; > > > _89 = (long unsigned int) _88; > > > _90 = VEC_SERIES_EXPR <0, _89>; > > > vect_cst__95 = [vec_duplicate_expr] m_17(D); > > > _97 = (sizetype) inc_x_20(D); > > > _98 = _97 * POLY_INT_CST [16, 16]; > > > _99 = (long unsigned int) inc_x_20(D); > > > _100 = _99 * 8; > > > _101 = (ssizetype) _100; > > > _102 = _101 /[ex] 8; > > > _103 = (long unsigned int) _102; > > > _104 = VEC_SERIES_EXPR <0, _103>; > > > _109 = (sizetype) inc_x_20(D); > > > _110 = _109 * POLY_INT_CST [16, 16]; > > > _111 = (long unsigned int) inc_x_20(D); > > > > The issue is you have two copies of > > (sizetype) inc_x_20(D) * POLY_INT_CST [16, 16]; > > and IVOPTs does not perform CSE. vinfo->ivexpr_map is supposed to > > catch those "IV base and/or step expressions". So look where > > they are inserted and check the CSE map is used. Alternatively > > fixup hashing/comparing to handle POLY_INT_CST [16, 16] if that > > is the reason for the missed CSE. > > > Yes, it's because cse_and_gimplify_to_preheader is not called for > gathering/scattering. Should be easily fixed by following patch: > > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c > index e7822c44951..ba9ee5c4996 100644 > --- a/gcc/tree-vect-stmts.c > +++ b/gcc/tree-vect-stmts.c > @@ -2961,6 +2961,7 @@ vect_get_strided_load_store_ops (stmt_vec_info > stmt_info, >tree bump = size_binop (MULT_EXPR, > fold_convert (sizetype, unshare_expr (DR_STEP > (dr))), > size_int (TYPE_VECTOR_SUBPARTS (vectype))); > + bump = cse_and_gimplify_to_preheader (loop_vinfo, bump); >*dataref_bump = force_gimple_operand (bump, , true, NULL_TREE); >if (stmts) > gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), stmts); I tested this patch and it worked fine on this testcase. Thanks a lot.
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #20 from Hongtao.liu ---
(In reply to Mark Wielaard from comment #19)
> (In reply to CVS Commits from comment #18)
> > gcc/testsuite/ChangeLog:
> > * gcc.target/i386/pr92658-avx512f.c: New test.
> > * gcc.target/i386/pr92658-avx512vl.c: Ditto.
> > * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto.
>
> Note that the second one as committed has an extra closing brace which
> causes an error:
>
> ERROR: gcc.target/i386/pr92658-avx512vl.c: unknown dg option: \} for "}"
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
> b/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
> index 50b32f968ac3..dc50084119b5 100644
> --- a/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
> +++ b/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
> @@ -121,7 +121,7 @@ truncdb_128 (v16qi * dst, v4si * __restrict src)
>dst[0] = *(v16qi *) tem;
> }
>
> -/* { dg-final { scan-assembler-times "vpmovqd" 2 } } } */
> +/* { dg-final { scan-assembler-times "vpmovqd" 2 } } */
> /* { dg-final { scan-assembler-times "vpmovqw" 2 { xfail *-*-* } } } */
> /* { dg-final { scan-assembler-times "vpmovqb" 2 { xfail *-*-* } } } */
> /* { dg-final { scan-assembler-times "vpmovdw" 1 } } */
Oh, sorry for typo.
[Bug tree-optimization/95281] New: ICE: in compute_live_loop_exits, at tree-ssa-loop-manip.c:247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95281
Bug ID: 95281
Summary: ICE: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Error:
>$g++ -O3 -c func.cpp
during GIMPLE pass: lim
func.cpp: In function ‘void c(bool, unsigned int*)’:
func.cpp:5:6: internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
5 | void c(bool d, unsigned e[]) {
| ^
0x827f56 compute_live_loop_exits
gcc_src/gcc/tree-ssa-loop-manip.c:247
0x827f56 add_exit_phis_var
gcc_src/gcc/tree-ssa-loop-manip.c:334
0x827f56 add_exit_phis
gcc_src/gcc/tree-ssa-loop-manip.c:356
0x827f56 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
gcc_src/gcc/tree-ssa-loop-manip.c:678
0x827f56 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
gcc_src/gcc/tree-ssa-loop-manip.c:631
0x1238f8b move_computations
gcc_src/gcc/tree-ssa-loop-im.c:1309
0x1238f8b tree_ssa_lim
gcc_src/gcc/tree-ssa-loop-im.c:3151
0x1238f8b execute
gcc_src/gcc/tree-ssa-loop-im.c:3198
Reproducer:
#include
short a;
extern short b[];
void c(bool d, unsigned e[]) {
for (short f = 0; f < 20; f += 4)
for (int g = 0; g < 23; g++) {
a = std::max(e[f], (unsigned)d);
b[g] = 5;
}
}
GCC version:
11.0.0 (bcb63eb2cbd3caf212b9cf42d8c218c09dc6ff8b)
[Bug tree-optimization/95273] [11 regression] many ICEs after r11-564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95273 --- Comment #1 from Bill Seurer --- Here's a full list: > FAIL: gcc.c-torture/execute/990128-1.c -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler > error) > FAIL: gcc.c-torture/execute/990128-1.c -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess > errors) > FAIL: gcc.c-torture/execute/990128-1.c -O3 -g (internal compiler error) > FAIL: gcc.c-torture/execute/990128-1.c -O3 -g (test for excess errors) > FAIL: gcc.c-torture/execute/loop-13.c -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler > error) > FAIL: gcc.c-torture/execute/loop-13.c -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess > errors) > FAIL: gcc.c-torture/execute/loop-13.c -O3 -g (internal compiler error) > FAIL: gcc.c-torture/execute/loop-13.c -O3 -g (test for excess errors) > FAIL: gcc.dg/pr48616.c (internal compiler error) > FAIL: gcc.dg/pr48616.c (test for excess errors) > FAIL: gcc.dg/pr86179.c (internal compiler error) > FAIL: gcc.dg/pr86179.c (test for excess errors) > FAIL: gcc.dg/torture/20181024-1.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (internal compiler error) > FAIL: gcc.dg/torture/20181024-1.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (test for excess errors) > FAIL: gcc.dg/torture/20181024-1.c -O3 -g (internal compiler error) > FAIL: gcc.dg/torture/20181024-1.c -O3 -g (test for excess errors) > FAIL: gcc.dg/torture/pr66856-1.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (internal compiler error) > FAIL: gcc.dg/torture/pr66856-1.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (test for excess errors) > FAIL: gcc.dg/torture/pr66856-1.c -O3 -g (internal compiler error) > FAIL: gcc.dg/torture/pr66856-1.c -O3 -g (test for excess errors) > FAIL: gcc.dg/torture/pr66856-2.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (internal compiler error) > FAIL: gcc.dg/torture/pr66856-2.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (test for excess errors) > FAIL: gcc.dg/torture/pr66856-2.c -O3 -g (internal compiler error) > FAIL: gcc.dg/torture/pr66856-2.c -O3 -g (test for excess errors) > FAIL: gcc.dg/torture/pr69168.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (internal compiler error) > FAIL: gcc.dg/torture/pr69168.c -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (test for excess errors) > FAIL: gcc.dg/torture/pr69168.c -O3 -g (internal compiler error) > FAIL: gcc.dg/torture/pr69168.c -O3 -g (test for excess errors) > FAIL: gcc.dg/torture/pr93428.c -O1 (internal compiler error) > FAIL: gcc.dg/torture/pr93428.c -O1 (test for excess errors) > FAIL: gcc.dg/torture/pr93428.c -O2 (internal compiler error) > FAIL: gcc.dg/torture/pr93428.c -O2 (test for excess errors) > FAIL: gcc.dg/torture/pr93428.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (internal compiler error) > FAIL: gcc.dg/torture/pr93428.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (test for excess errors) > FAIL: gcc.dg/torture/pr93428.c -O3 -g (internal compiler error) > FAIL: gcc.dg/torture/pr93428.c -O3 -g (test for excess errors) > FAIL: gcc.dg/torture/pr93428.c -Os (internal compiler error) > FAIL: gcc.dg/torture/pr93428.c -Os (test for excess errors) > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c (internal compiler error) > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c (test for excess errors) > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects > scan-tree-dump slp2 "demoting int to unsigned short" > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects > scan-tree-dump-times slp2 "basic block vectorized" 2 > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects (internal > compiler error) > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects (test for > excess errors) > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump slp2 "demoting int to > unsigned short" > FAIL: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump-times slp2 "basic > block vectorized" 2 > FAIL: gcc.dg/vect/bb-slp-over-widen-2.c (internal compiler error) > FAIL: gcc.dg/vect/bb-slp-over-widen-2.c (test for excess errors) > FAIL: gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects > scan-tree-dump slp2 "demoting int to unsigned short" > FAIL: gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects > scan-tree-dump-times slp2 "basic block vectorized" 2 > FAIL: gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects (internal > compiler error) > FAIL:
[Bug c/95280] poor warning for attribute used on a function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95280 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37874 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- While touching the code affecting attributes on function arguments, it might also be worth taking a look at bug 37874
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #19 from Mark Wielaard ---
(In reply to CVS Commits from comment #18)
> gcc/testsuite/ChangeLog:
> * gcc.target/i386/pr92658-avx512f.c: New test.
> * gcc.target/i386/pr92658-avx512vl.c: Ditto.
> * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto.
Note that the second one as committed has an extra closing brace which causes
an error:
ERROR: gcc.target/i386/pr92658-avx512vl.c: unknown dg option: \} for "}"
diff --git a/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
b/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
index 50b32f968ac3..dc50084119b5 100644
--- a/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
+++ b/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
@@ -121,7 +121,7 @@ truncdb_128 (v16qi * dst, v4si * __restrict src)
dst[0] = *(v16qi *) tem;
}
-/* { dg-final { scan-assembler-times "vpmovqd" 2 } } } */
+/* { dg-final { scan-assembler-times "vpmovqd" 2 } } */
/* { dg-final { scan-assembler-times "vpmovqw" 2 { xfail *-*-* } } } */
/* { dg-final { scan-assembler-times "vpmovqb" 2 { xfail *-*-* } } } */
/* { dg-final { scan-assembler-times "vpmovdw" 1 } } */
[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 Jason Merrill changed: What|Removed |Added Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed.
[Bug c/95280] New: poor warning for attribute used on a function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95280 Bug ID: 95280 Summary: poor warning for attribute used on a function argument Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- GCC warns when attribute used is specified on a function argument (e.g., as a mistake instead of unused) but the warning is devoid of any useful information: $ cat z.c && gcc -S -Wall -Wextra z.c int f (int __attribute__ ((used)) i); z.c:1:1: warning: ‘used’ attribute ignored [-Wattributes] 1 | int f (int __attribute__ ((used)) i); | ^~~ In contrast, Clang issues a much more informative message: z.c:1:28: warning: 'used' attribute only applies to variables with non-local storage, functions, and Objective-C methods [-Wignored-attributes] int f (int __attribute__ ((used)) i); ^ 1 warning generated.
[Bug sanitizer/95279] New: UBSan doesn't seem to detect pointer overflow in certain cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
Bug ID: 95279
Summary: UBSan doesn't seem to detect pointer overflow in
certain cases
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: frantisek at sumsal dot cz
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 48583
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48583=edit
repro.i
Hello,
One of our systemd fuzzers caught a pointer overflow issue and after adding the
reproducer into our test suite I noticed that the scenario seems to be detected
only by clang - gcc remains silent.
Reproducer:
#include
#include
int main(int argc, char *argv[]) {
const void *p = (uint8_t*)0x406310;
size_t s = -1;
void *r;
r = (uint8_t*)p + s;
printf("0x%lx\n", (unsigned long)r);
return 0;
}
### gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)
$ export UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1
$ gcc -fsanitize=undefined -g -save-temps -o repro repro.c
$ ./repro
0x40630f
### clang version 10.0.0 (Fedora 10.0.0-1.fc33)
$ export UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1
$ clang -fsanitize=undefined -g -save-temps -o repro repro.c
$ ./repro
repro.c:9:18: runtime error: addition of unsigned offset to 0x00406310
overflowed to 0x0040630f
#0 0x427f1b in main /root/systemd/repro.c:9:18
#1 0x7f5e0cbd3151 in __libc_start_main (/lib64/libc.so.6+0x27151)
#2 0x40347d in _start (/root/systemd/repro+0x40347d)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior repro.c:9:18 in
[Bug middle-end/95278] New: attribute nonstring effect on arguments in function declaration that's not a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95278
Bug ID: 95278
Summary: attribute nonstring effect on arguments in function
declaration that's not a definition
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: ---
strlen calls in both functions below should be diagnosed because the
declaration with the attribute is likely to be in a header and thus come first,
and it's what determines what calls can be diagnosed. Unfortunately, the more
likely case is not diagnosed.
$ cat z.c && gcc -S -Wall -Wextra z.c
int f (const char *);
int f (const char __attribute__ ((nonstring)) *p)
{
return __builtin_strlen (p); // warning (good)
}
int g (const char __attribute__ ((nonstring))*);
int g (const char *p)
{
return __builtin_strlen (p); // missing warning
}
z.c: In function ‘f’:
z.c:5:10: warning: ‘__builtin_strlen’ argument 1 declared attribute ‘nonstring’
[-Wstringop-overflow=]
5 | return __builtin_strlen (p); // warning (good)
| ^~~~
z.c:3:48: note: argument ‘p’ declared here
3 | int f (const char __attribute__ ((nonstring)) *p)
|^
[Bug middle-end/95277] New: error on alignment for a function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95277
Bug ID: 95277
Summary: error on alignment for a function argument
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: ---
Declaring a local variable with attribute aligned is accepted. Declaring a
function argument with an overligned type is also accepted.
However, specifying attribute aligned on a function argument is rejected. The
error doesn't say why the attribute may not be specified, and the manual
doesn't say that specifying the attribute on function arguments is not allowed.
The same code is accepted by Clang.
Either the code should be accepted with the same effect as in Clang, or the
manual (and ideally also the error) should be updated to explain why the
attribute may not be specified this way.
$ cat z.c && gcc -S -Wall -Wextra z.c
void f (void)
{
__attribute__ ((aligned (256))) char c; // accepted
_Static_assert (__alignof__ (c) == 256, "#1"); // passes
}
typedef __attribute__ ((aligned (256))) char C256;
void g (C256 c)// accepted
{
_Static_assert (__alignof__ (c) == 256, "#2"); // passes
}
void h (__attribute__ ((aligned (256))) char c)// error
{
_Static_assert (__alignof__ (c) == 256, "#3");
}
z.c:14:46: error: alignment may not be specified for ‘c’
14 | void h (__attribute__ ((aligned (256))) char c)// error
| ~^
z.c: In function ‘h’:
z.c:16:3: error: static assertion failed: "#3"
16 | _Static_assert (__alignof__ (c) == 256, "#3");
| ^~
[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276 Martin Sebor changed: What|Removed |Added Last reconfirmed||2020-05-22 Status|UNCONFIRMED |WAITING CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Can you please reduce that to a test case or a translation unit?
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch submitted for review: https://gcc.gnu.org/pipermail/fortran/2020-May/054373.html
[Bug other/87695] Arduino: ICE with avr and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||eweddington at gcc dot gnu.org, ||senthil.thecoder at gmail dot com --- Comment #19 from Eric Gallager --- cc-ing Senthil Kumar since apparently he's at Microchip and still working on AVR stuff: https://gcc.gnu.org/pipermail/gcc/2020-April/000412.html
[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |11.0
[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276 Thomas Koenig changed: What|Removed |Added Summary|Amusing stringpop-overflow |[11 Regression] Amusing |message building|stringpop-overflow message |libgfortran on power9 |building libgfortran Component|target |middle-end --- Comment #1 from Thomas Koenig --- Also found on x86_64. Not sure where this belongs, but it looks like a regression.
[Bug target/95276] New: Amusing stringpop-overflow message building libgfortran on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276 Bug ID: 95276 Summary: Amusing stringpop-overflow message building libgfortran on power9 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Just noted this building libgfortran on powerpc64le-unknown-linux-gnu: ../../../trunk/libgfortran/io/write.c: In Funktion »write_z«: ../../../trunk/libgfortran/io/write.c:1181:6: Warnung: Schreiben von 140735240075856 Byte in eine Region der Größe 1 [-Wstringop-overflow=] 1181 | *q = '\0'; | ~~~^~ I never thought a single byte could be _that_ big. The hex number is 0x7fff79fdfa50, which I don't recognize. This is with trunk dc50686d78d4679b727548c3edc1cb6b0d3b658e.
[Bug sanitizer/95275] Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95275 --- Comment #1 from Frantisek Sumsal --- Created attachment 48582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48582=edit perf call graph Attaching a perf call graph screenshot (as the text one got shattered by formatting).
[Bug sanitizer/95275] New: Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95275 Bug ID: 95275 Summary: Possible performance regression in libasan with detect_stack_use_after_return=1 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: frantisek at sumsal dot cz 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: --- Hello, This appears to be part #2 to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101 as we managed to hit the issue once again[0], but in a different codepath. Reproducer: $ git clone https://github.com/systemd/systemd $ git fetch -fu origin refs/pull/15886/merge:pr $ git checkout pr $ meson build-gcc -Db_sanitize=address,undefined -Dfuzz-tests=true --optimization=1 $ ninja -C build-gcc $ export ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1 $ export UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 $ time build-gcc/fuzz-unit-file\:address\,undefined test/fuzz/fuzz-unit-file/oss-fuzz-11569 Results: ### gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0.11) $ time build-gcc/fuzz-unit-file\:address\,undefined test/fuzz/fuzz-unit-file/oss-fuzz-11569 test/fuzz/fuzz-unit-file/oss-fuzz-11569... ok real3m22.804s user3m18.725s sys 0m0.245s ### gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0.11) with detect_stack_use_after_return=0 $ export ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=0:check_initialization_order=1:strict_init_order=1 $ time build-gcc/fuzz-unit-file\:address\,undefined test/fuzz/fuzz-unit-file/oss-fuzz-11569 test/fuzz/fuzz-unit-file/oss-fuzz-11569... ok real0m2.803s user0m2.731s sys 0m0.060s ### clang version 10.0.0 (Fedora 10.0.0-0.3.rc4.fc32) for comparison $ time build-clang/fuzz-unit-file\:address\,undefined test/fuzz/fuzz-unit-file/oss-fuzz-11569 test/fuzz/fuzz-unit-file/oss-fuzz-11569... ok real0m3.222s user0m3.104s sys 0m0.089s ### perf # Samples: 862K of event 'cycles:u' # Event count (approx.): 873078595486 # # Overhead Command Shared Object Symbol # ... . # 95.14% fuzz-unit-file: libasan.so.6.0.0 [.] __asan_stack_malloc_0 3.13% fuzz-unit-file: libasan.so.6.0.0 [.] __asan_stack_malloc_1 0.18% fuzz-unit-file: libc-2.31.so [.] __strlen_avx2 0.17% fuzz-unit-file: libasan.so.6.0.0 [.] __asan_stack_malloc_2 0.15% fuzz-unit-file: libasan.so.6.0.0 [.] __asan_region_is_poisoned 0.07% fuzz-unit-file: libc-2.31.so [.] __strchr_avx2 0.06% fuzz-unit-file: libsystemd-shared-245.so [.] utf8_encoded_valid_unichar ... ### perf (call graph) # Samples: 804K of event 'cycles:u' # Event count (approx.): 811179153673 # # Children Self Command Shared Object Symbol # ... . # 99.97% 0.00% fuzz-unit-file: fuzz-unit-file[.] LLVMFuzzerTestOneInput | ---LLVMFuzzerTestOneInput | --99.57%--config_parse | --99.56%--parse_line | |--93.39%--next_assignment (inlined) | | | --93.39%--config_parse_unit_requires_mounts_for | | | |--88.89%--path_simplify_and_warn | | | | | --88.87%--utf8_is_valid | | | | | --88.85%--utf8_encoded_valid_unichar | | | | | --88.79%--__asan_stack_malloc_0 | | | --4.09%--unit_full_printf | specifier_printf
[Bug bootstrap/95274] 0896cc4276b6 broke boostrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95274 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Thomas Koenig --- Hm, I would have thought that this was recognized... Anyway, this has now been fixed by gcc r11-576, so I can close this.
[Bug bootstrap/95274] New: 0896cc4276b6 broke boostrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95274 Bug ID: 95274 Summary: 0896cc4276b6 broke boostrap Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- 0896cc4276b6 (Jan Hubicka2020-05-22 15:44:10 +0200 806) fprintf (streamer_dump_file, 0896cc4276b6 (Jan Hubicka2020-05-22 15:44:10 +0200 807) " Streaming single tree\n", size); ../../trunk/gcc/lto-streamer-out.c: In Konstruktor »DFS::DFS(output_block*, tree, bool, bool, bool)«: ../../trunk/gcc/lto-streamer-out.c:807:10: Fehler: zu viele Argumente für Format [-Werror=format-extra-args] 807 | " Streaming single tree\n", size); | ^~
[Bug tree-optimization/95273] New: [11 regression] many ICEs after r11-564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95273 Bug ID: 95273 Summary: [11 regression] many ICEs after r11-564 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- One example: Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr48616.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -ftree-vectorize -lm -o ./pr48616.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr48616.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -ftree-vectorize -lm -o ./pr48616.exe during GIMPLE pass: slp /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr48616.c: In function 'fn3': /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/pr48616.c:58:1: internal compiler error: in vect_get_constant_vectors, at tree-vect-slp.c:3638 0x10ef206f vect_get_constant_vectors /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3635 0x10ef3533 vect_get_slp_defs(vec_info*, _slp_tree*, vec, va_heap, vl_ptr>*, unsigned int) /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3872 0x10e9e5e7 vect_get_vec_defs(vec_info*, tree_node*, tree_node*, _stmt_vec_info*, vec*, vec*, _slp_tree*) /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-stmts.c:1636 0x10ea4bbf vectorizable_shift /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-stmts.c:5883 0x10ec01ab vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*) /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-stmts.c:11165 0x10ef4653 vect_schedule_slp_instance /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4220 0x10ef4363 vect_schedule_slp_instance /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4112 0x10eff193 vect_schedule_slp(vec_info*) /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4344 0x10f01633 vect_slp_bb_region /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3298 0x10f01633 vect_slp_bb(basic_block_def*) /home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3421 0x10f0393b execute /home/seurer/gcc/git/gcc-test2/gcc/tree-vectorizer.c:1320
[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Thomas Koenig --- And now really closing, and thanks for the bug report.
[Bug c++/95272] New: ice in vectorizable_reduction, at tree-vect-loop.c:6197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95272
Bug ID: 95272
Summary: ice in vectorizable_reduction, at
tree-vect-loop.c:6197
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: ---
For this C++ code:
enum { a = 5, b };
typedef struct {
int c[b];
} d;
extern d e[];
int f;
int g[6];
void h() {
int i;
for (; f; f++) {
i = 0;
for (; i < b; i++)
if (e[f].c[i])
g[i] = e[f].c[i];
}
}
compiled by recent gcc trunk and compiler flags -w -c -O3 -march=cooperlake,
I get:
during GIMPLE pass: vect
bug613.cc: In function ‘void h()’:
bug613.cc:8:6: internal compiler error: in vectorizable_reduction, at
tree-vect-
loop.c:6197
8 | void h() {
| ^
0x11e91f5 vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*,
_
slp_instance*, vec*)
../../trunk.git/gcc/tree-vect-loop.c:6197
0x11bb55d vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_
instance*, vec*)
../../trunk.git/gcc/tree-vect-stmts.c:11067
0x120767d vect_slp_analyze_node_operations_1(vec_info*, _slp_tree*,
_slp_instanc
e*, vec*)
../../trunk.git/gcc/tree-vect-slp.c:2676
0x120767d 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:2844
The problem first seems to occur sometime between dates 20200521 and
20200522. git hashes f094665d465..e740f3d7314
[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95255 --- Comment #4 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:1a030003858d853f564ed354f1cb579c03db17ef commit r11-575-g1a030003858d853f564ed354f1cb579c03db17ef Author: Uros Bizjak Date: Fri May 22 18:02:49 2020 +0200 i386: Fix 2 expander [PR95255] 2020-05-22 Uroš Bizjak gcc/ChangeLog: PR target/95255 * config/i386/i386.md (2): Do not try to expand non-sse4 ROUND_ROUNDEVEN rounding via SSE support routines. gcc/testsuite/ChangeLog: PR target/95255 * gcc.target/i386/pr95255.c: New test.
[Bug c/95271] New: ice in vect_get_constant_vectors, at tree-vect-slp.c:3638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95271
Bug ID: 95271
Summary: ice in vect_get_constant_vectors, at
tree-vect-slp.c:3638
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: ---
For this C code:
int a;
struct b c;
long d;
struct b {
unsigned long address;
unsigned long e;
};
void f() {
{
d = (long)()[0] << 56 | (long)((unsigned char *))[1] << 48 |
(long)((unsigned char *))[2] << 40 |
(long)((unsigned char *))[3] << 32 |
(long)((unsigned char *))[4] << 24 | ((unsigned char *))[5] << 16 |
((unsigned char *))[6] << 8 | ((unsigned char *))[7];
}
c.address = c.e = d;
}
compiled with recent gcc trunk and compiler flags -c -w -O3 -march=cooperlake
does this:
during GIMPLE pass: slp
bug612.c: In function ‘f’:
bug612.c:8:6: internal compiler error: in vect_get_constant_vectors, at
tree-vect-slp.c:3638
8 | void f() {
| ^
0xf95b4b vect_get_constant_vectors(vec_info*, _slp_tree*, unsigned int,
vec*)
../../trunk.git/gcc/tree-vect-slp.c:3635
0xf95b4b vect_get_slp_defs(vec_info*, _slp_tree*, vec, va_heap, vl_ptr>*, unsigned int)
../../trunk.git/gcc/tree-vect-slp.c:3872
0xf4529a vect_get_vec_defs(vec_info*, tree_node*, tree_node*, _stmt_vec_info*,
v
ec*, vec*,
_slp_tree*)
../../trunk.git/gcc/tree-vect-stmts.c:1636
0xf48bfc vectorizable_bswap(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
_
stmt_vec_info**, _slp_tree*, tree_node*, vec*)
The bug first appears sometime between 20200521 and 20200522, marked
by git hashes f094665d465..e740f3d7314.
[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-22 --- Comment #5 from Bill Schmidt --- I'd like to understand why the difference between -O2 and -O3 exists. We shouldn't generate this kind of nasty store-load at -O2. Confirmed, BTW. :)
[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 --- Comment #10 from Thomas Koenig --- Closed on all affected branches, after the now-customary battles with git.
[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:f1d34396c264ae15ba7492bd2b800c5764d92134 commit r9-8615-gf1d34396c264ae15ba7492bd2b800c5764d92134 Author: Thomas Koenig Date: Thu May 14 18:30:27 2020 +0200 Add early return for invalid STATUS for close. 2020-05-14 Thomas Koenig PR libfortran/95119 * io/close.c (close_status): Add CLOSE_INVALID. (st_close): Return early on invalid STATUS parameter. 2020-05-14 Thomas Koenig PR libfortran/95119 * testsuite/libgomp.fortran/close_errors_1.f90: New test. (cherry picked from commit cdc34b505796327b3eee9e97bc5f27ba71fd9e7a) (cherry picked from commit d975519ad1066ed0397714c91aafadadb52a63dd) (cherry picked from commit 8275e0a6686b465d4d1717784e3e864305d37d02)
[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199 --- Comment #7 from bin cheng --- (In reply to rguent...@suse.de from comment #6) > On Thu, 21 May 2020, zhoukaipeng3 at huawei dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199 > > > > --- Comment #4 from Kaipeng Zhou --- > > Sorry for not expressing clearly. > > > > I have debugged the testcase you provided. Not eliminating them is not > > caused > > by IFN. The relevant code is in the "get_computation_aff_1" function. > > > > In IVOPTs the IV_STEPs must be checked by function "constant_multiple_of" > > before using an IV variable to eliminate the other. But if the tree_code of > > input IV_STEP is SSA_NAME, the function will return false. In your > > testcase, > > the tree_code of IV_STEP is MULT_EXPR, so it return true. > > > > Gimple for my testcase: > >[local count: 8589933]: > > _83 = (sizetype) inc_y_22(D); > > _84 = _83 * POLY_INT_CST [16, 16]; > > _85 = (long unsigned int) inc_y_22(D); > > _86 = _85 * 8; > > _87 = (ssizetype) _86; > > _88 = _87 /[ex] 8; > > _89 = (long unsigned int) _88; > > _90 = VEC_SERIES_EXPR <0, _89>; > > vect_cst__95 = [vec_duplicate_expr] m_17(D); > > _97 = (sizetype) inc_x_20(D); > > _98 = _97 * POLY_INT_CST [16, 16]; > > _99 = (long unsigned int) inc_x_20(D); > > _100 = _99 * 8; > > _101 = (ssizetype) _100; > > _102 = _101 /[ex] 8; > > _103 = (long unsigned int) _102; > > _104 = VEC_SERIES_EXPR <0, _103>; > > _109 = (sizetype) inc_x_20(D); > > _110 = _109 * POLY_INT_CST [16, 16]; > > _111 = (long unsigned int) inc_x_20(D); > > The issue is you have two copies of > (sizetype) inc_x_20(D) * POLY_INT_CST [16, 16]; > and IVOPTs does not perform CSE. vinfo->ivexpr_map is supposed to > catch those "IV base and/or step expressions". So look where > they are inserted and check the CSE map is used. Alternatively > fixup hashing/comparing to handle POLY_INT_CST [16, 16] if that > is the reason for the missed CSE. > Yes, it's because cse_and_gimplify_to_preheader is not called for gathering/scattering. Should be easily fixed by following patch: diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index e7822c44951..ba9ee5c4996 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -2961,6 +2961,7 @@ vect_get_strided_load_store_ops (stmt_vec_info stmt_info, tree bump = size_binop (MULT_EXPR, fold_convert (sizetype, unshare_expr (DR_STEP (dr))), size_int (TYPE_VECTOR_SUBPARTS (vectype))); + bump = cse_and_gimplify_to_preheader (loop_vinfo, bump); *dataref_bump = force_gimple_operand (bump, , true, NULL_TREE); if (stmts) gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), stmts);
[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:8275e0a6686b465d4d1717784e3e864305d37d02 commit r10-8170-g8275e0a6686b465d4d1717784e3e864305d37d02 Author: Thomas Koenig Date: Thu May 14 18:30:27 2020 +0200 Add early return for invalid STATUS for close. 2020-05-14 Thomas Koenig PR libfortran/95119 * io/close.c (close_status): Add CLOSE_INVALID. (st_close): Return early on invalid STATUS parameter. 2020-05-14 Thomas Koenig PR libfortran/95119 * testsuite/libgomp.fortran/close_errors_1.f90: New test. (cherry picked from commit cdc34b505796327b3eee9e97bc5f27ba71fd9e7a) (cherry picked from commit d975519ad1066ed0397714c91aafadadb52a63dd)
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658 --- Comment #18 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e740f3d73144abbca1ad98a04825c6bd63314a0b commit r11-571-ge740f3d73144abbca1ad98a04825c6bd63314a0b Author: liuhongt Date: Wed May 20 15:53:14 2020 +0800 Add missing vector truncmn2 expanders [PR92658] 2020-05-22 Hongtao.liu gcc/ChangeLog: PR target/92658 * config/i386/sse.md (trunc2): New expander (truncv32hiv32qi2): Ditto. (trunc2): Ditto. (trunc2): Ditto. (trunc2): Ditto. (truncv2div2si2): Ditto. (truncv8div8qi2): Ditto. (avx512f_v8div16qi2): Renaming from *avx512f_v8div16qi2. (avx512vl_v2div2si): Renaming from *avx512vl_v2div2si2. (avx512vl_v2qi2): Renaming from *avx512vl_vqi2. gcc/testsuite/ChangeLog: * gcc.target/i386/pr92658-avx512f.c: New test. * gcc.target/i386/pr92658-avx512vl.c: Ditto. * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto.
[Bug middle-end/95270] New: OpenACC 'enter data attach(data_p)' fails for 'int *data_p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95270 Bug ID: 95270 Summary: OpenACC 'enter data attach(data_p)' fails for 'int *data_p' Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Created attachment 48581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48581=edit 'mdc-2b_.c' See test case attached: 'acc_attach(_p)' works, '#pragma enter data attach(data_p)' doesn't. In such a case, I suppose we either need to explicitly set 'OMP_CLAUSE_SIZE' in all front ends, or otherwise make sure to skip/invalidate the 'gcc/gimplify.c:gimplify_scan_omp_clauses' handling: if (OMP_CLAUSE_SIZE (c) == NULL_TREE) OMP_CLAUSE_SIZE (c) = DECL_P (decl) ? DECL_SIZE_UNIT (decl) : TYPE_SIZE_UNIT (TREE_TYPE (decl)); ..., or elsewhere? Given that for 'GOMP_MAP_ATTACH' etc. this is a *bias*, not a *size*, I'd like to see this explicitly mentioned/handled in the code, under the assumption that for 'GOMP_MAP_STRUCT'-related 'GOMP_MAP_ATTACH', we do need this set non-zero. Also need to update the comments in 'include/gomp-constants.h:enum gomp_map_kind' to explain that (see 'GOMP_MAP_POINTER' example?).
[Bug target/95258] -march=native doesn't handle -mavx512vpopcntdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 --- Comment #2 from H.J. Lu --- Fixed for GCC 11 so far.
[Bug target/94282] [amdgcn] ld: error: undefined symbol: __gxx_personality_v0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94282 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Status|NEW |RESOLVED See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=94248,| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=92713,| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=71959 | Resolution|--- |FIXED --- Comment #9 from Thomas Schwinge --- .
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 --- Comment #8 from Freddie Witherden --- (In reply to rguent...@suse.de from comment #7) > > Instead of [[gnu::flatten]] you could use the > __attribute__((always_inline)) attribute on the foo function definition > if you didn't simplify the outline above too much to make that > infeasible. IIRC we do not have sth like > > [[gnu::inline]] foo(i, ...); > > to force inlining of a specific call, nor [[gnu::noinline]] foo(i, ...); > both which seem useful. Not sure if the C++ syntax would support > such placement of an attribute of course. So this is exactly what we had in the pre-flatten version of the code: https://github.com/PyFR/Polyquad/commit/f24366c059d2d693222985cdd9333238bd909ad3 The issue was while GCC would inline the annotated functions it would go no further. As such, if I recall correctly, all of the constructor calls to the relatively simple Eigen vector types were no longer inlined. Thus a line of code which should translate into a few register-to-memory mov instructions results in a a constructor call, an assignment call, and some cleanup. Since I could not add the force inline attribute to the library types I went in search of an alternative. For the T = bfloat eval_orthob instance is the "if (std::is_fundamental::value)" considered before the body is inlined?
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 --- Comment #7 from rguenther at suse dot de --- On Fri, 22 May 2020, freddie at witherden dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 > > --- Comment #6 from Freddie Witherden --- > (In reply to Richard Biener from comment #3) > > So with the [[gnu::flatten]] attributes removed -O1 needs 80 seconds to > > compile and about 3GB of memory, -O2 needs around 2 minutes (same memory), > > -O3 > > is the same as -O2. > > > > Maybe instead of [[gnu::flatten]] you want to bump --param > > inline-unit-growth > > or --param large-function-growth more moderately in case you can measure an > > effect on runtime. > > > > Note multiple [[gnu::flatten]] can really exponentially grow program size > > since it is not appearant which functions might be used from another > > translation unit until you can use -fwhole-program (single CU program) > > or -flto (but there [[gnu::flatten]] is applied to early to avoid such > > growth - sth we might want to fix). Placing things not used from outside > > in anonymous namespaces might help. > > The [[gnu::flatten]] was added to get GCC's performance in the case of T = > double on a par with Clang's. (We don't care about performance with T = > bfloat > as it is just used as a final polishing pass.) I can understand why GCC does > not want to inline it in the case of T = bfloat which is a complex type, but > for T = double the function is basically just a sequence of mov's to populate > an array. > > As the function is of the form > > for (int i = 0; i < N; i++) // N = template arg > for (int j = 0; j < p[N]; j++) // runtime trip count > foo(i, ...); // static polymorphism > > with foo being a large switch-case on its first argument the expectation was > for the compiler to inline foo, unroll the outer loop, and then prune the dead > cases such that we have something similar to > > for (int j = 0; j < p[0]; j++) > foo(0, ...); // inline i = 0 case > for (int j = 0; j < p[1]; j++) > foo(1, ...); // inline i = 1 case > // ... Ah, interesting. This kind of static polymorphism should be handled by IPA-CP already but it's of course possible we're confused about a detail in this very testcase. Honza? Instead of [[gnu::flatten]] you could use the __attribute__((always_inline)) attribute on the foo function definition if you didn't simplify the outline above too much to make that infeasible. IIRC we do not have sth like [[gnu::inline]] foo(i, ...); to force inlining of a specific call, nor [[gnu::noinline]] foo(i, ...); both which seem useful. Not sure if the C++ syntax would support such placement of an attribute of course.
[Bug tree-optimization/94945] Missed optimization: Carry chain not recognized in manually unrolled loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94945 Madhur Chauhan changed: What|Removed |Added Version|10.0|10.1.1 Component|rtl-optimization|tree-optimization --- Comment #1 from Madhur Chauhan --- Is the scope of this optimization too narrow?
[Bug tree-optimization/95268] ICE: invalid ‘PHI’ argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95268 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #21 from Iain Sandoe --- (In reply to Rafael Avila de Espindola from comment #20) > The attached testcase also fails with just -fsanitize=undefined. I have > tested with gcc version > > gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1) thanks Rafael, I confirm this is repeatable for me on both master and 10.1 (and, also that patches in my queue fix it for at least master [on Darwin]) doing some wider testing now.
[Bug target/95258] -march=native doesn't handle -mavx512vpopcntdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95258 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:808b611bfb4b05703ea174e50874c711dca44c98 commit r11-570-g808b611bfb4b05703ea174e50874c711dca44c98 Author: H.J. Lu Date: Fri May 22 04:18:34 2020 -0700 x86: Handle -mavx512vpopcntdq for -march=native Add -mavx512vpopcntdq for -march=native if AVX512VPOPCNTDQ is available. PR target/95258 * config/i386/driver-i386.c (host_detect_local_cpu): Detect AVX512VPOPCNTDQ.
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 --- Comment #6 from Freddie Witherden --- (In reply to Richard Biener from comment #3) > So with the [[gnu::flatten]] attributes removed -O1 needs 80 seconds to > compile and about 3GB of memory, -O2 needs around 2 minutes (same memory), > -O3 > is the same as -O2. > > Maybe instead of [[gnu::flatten]] you want to bump --param inline-unit-growth > or --param large-function-growth more moderately in case you can measure an > effect on runtime. > > Note multiple [[gnu::flatten]] can really exponentially grow program size > since it is not appearant which functions might be used from another > translation unit until you can use -fwhole-program (single CU program) > or -flto (but there [[gnu::flatten]] is applied to early to avoid such > growth - sth we might want to fix). Placing things not used from outside > in anonymous namespaces might help. The [[gnu::flatten]] was added to get GCC's performance in the case of T = double on a par with Clang's. (We don't care about performance with T = bfloat as it is just used as a final polishing pass.) I can understand why GCC does not want to inline it in the case of T = bfloat which is a complex type, but for T = double the function is basically just a sequence of mov's to populate an array. As the function is of the form for (int i = 0; i < N; i++) // N = template arg for (int j = 0; j < p[N]; j++) // runtime trip count foo(i, ...); // static polymorphism with foo being a large switch-case on its first argument the expectation was for the compiler to inline foo, unroll the outer loop, and then prune the dead cases such that we have something similar to for (int j = 0; j < p[0]; j++) foo(0, ...); // inline i = 0 case for (int j = 0; j < p[1]; j++) foo(1, ...); // inline i = 1 case // ...
[Bug tree-optimization/95268] ICE: invalid ‘PHI’ argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95268 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7c592aad23c22b9f37020cd0a7475d8f3938 commit r11-568-g7c592aad23c22b9f37020cd0a7475d8f3938 Author: Richard Biener Date: Fri May 22 09:03:40 2020 +0200 tree-optimization/95268 - fix commoning of clobbers This fixes handling of clobbers when commoning stores. 2020-05-22 Richard Biener PR tree-optimization/95268 * tree-ssa-sink.c (sink_common_stores_to_bb): Handle clobbers properly. * g++.dg/torture/pr95268.C: New testcase.
[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95255 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #3 from Uroš Bizjak --- Created attachment 48580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48580=edit patch in testing.
[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 --- Comment #7 from Jonathan Wakely --- Compare to e.g. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1825 which says "[Moved to DR at the November, 2016 meeting.]" That means it's a retroactive fix for previous standards. That isn't the case for 727.
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Richard Biener --- Fixed.
[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 --- Comment #6 from Jonathan Wakely --- (In reply to Rustam Abdullaev from comment #5) > (In reply to Jonathan Wakely from comment #3) > > https://wg21.link/cwg727 > > > > N.B. this is a C++17 feature that does not seem to have been approved as a > > DR, but Clang supports it in all language modes. > > > CWG 727 says "Adopted at the February/March, 2017 meeting", and > [temp.class.spec]/5 in ISO/IEC 14882:2017(E) is reflecting the new wording. > So this is in C++17. The defect is on GCC side. Yes. That's what I said. But it's not a DR, so it only applies to C++17 and not C++14 or older standards.
[Bug lto/95190] Documentation for -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a24d9b5bbb6a298ff4e55d731d5e436b0da9e38a commit r10-8169-ga24d9b5bbb6a298ff4e55d731d5e436b0da9e38a Author: Richard Biener Date: Tue May 19 08:36:13 2020 +0200 lto/95190 - amend -flto docs for diagnostic option handling This documents new GCC 10 behavior on diagnostic options and -flto. 2020-05-22 Richard Biener PR lto/95190 * doc/invoke.texi (flto): Document behavior of diagnostic options. (cherry picked from commit ab7eca92926fdc1da880120c116a1832fce56a29)
[Bug lto/95190] Documentation for -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ab7eca92926fdc1da880120c116a1832fce56a29 commit r11-565-gab7eca92926fdc1da880120c116a1832fce56a29 Author: Richard Biener Date: Tue May 19 08:36:13 2020 +0200 lto/95190 - amend -flto docs for diagnostic option handling This documents new GCC 10 behavior on diagnostic options and -flto. 2020-05-22 Richard Biener PR lto/95190 * doc/invoke.texi (flto): Document behavior of diagnostic options.
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 --- Comment #5 from Richard Biener --- So confirmed we eventually blow up at -O1: ++: fatal error: Killed signal terminated program cc1plus compilation terminated. Command exited with non-zero status 1 3015.48user 45.01system 1:08:57elapsed 73%CPU (0avgtext+0avgdata 30682104maxresident)k 1549456inputs+47040outputs (2343major+9807077minor)pagefaults 0swaps didn't manage to catch where in the process of compilation that was though, during PTA it hovered at ~12GB.
[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 --- Comment #5 from Rustam Abdullaev --- (In reply to Jonathan Wakely from comment #3) > https://wg21.link/cwg727 > > N.B. this is a C++17 feature that does not seem to have been approved as a > DR, but Clang supports it in all language modes. > CWG 727 says "Adopted at the February/March, 2017 meeting", and [temp.class.spec]/5 in ISO/IEC 14882:2017(E) is reflecting the new wording. So this is in C++17. The defect is on GCC side.
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Richard Biener --- clang documentation mentions they support [[gnu::flatten]], whether implementations match here is of course another question. I guess for a convoluted cgraph our flatten implementation leaves sth to be desired - if there's two calls to the same function we inline it fully twice and have to reap benefits of inlining all calls (recursively) in them twice rather than producing an optimized body for the flatten inlining first. One could envision some early cloning for the purpose of flattening, pushing down the flattening attribute to the clones that end up being inlined multiple times. Not sure how easy that would be - Honza?
[Bug tree-optimization/95248] [11 Regression] GCC produces incorrect code with -O3 for loops since r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95248 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/95248] [11 Regression] GCC produces incorrect code with -O3 for loops since r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95248 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b6ed2e2bca54d1d290f553549d28b0c60a0f240f commit r11-563-gb6ed2e2bca54d1d290f553549d28b0c60a0f240f Author: Richard Biener Date: Fri May 22 08:48:04 2020 +0200 tree-optimization/95248 - fix oversight in SM rewrite This fixes a leftover early out in determining the sequence of stores to materialize. 2020-05-22 Richard Biener PR tree-optimization/95248 * tree-ssa-loop-im.c (sm_seq_valid_bb): Remove bogus early out. * gcc.dg/torture/pr95248.c: New testcase.
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-05-22 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- So with the [[gnu::flatten]] attributes removed -O1 needs 80 seconds to compile and about 3GB of memory, -O2 needs around 2 minutes (same memory), -O3 is the same as -O2. Maybe instead of [[gnu::flatten]] you want to bump --param inline-unit-growth or --param large-function-growth more moderately in case you can measure an effect on runtime. Note multiple [[gnu::flatten]] can really exponentially grow program size since it is not appearant which functions might be used from another translation unit until you can use -fwhole-program (single CU program) or -flto (but there [[gnu::flatten]] is applied to early to avoid such growth - sth we might want to fix). Placing things not used from outside in anonymous namespaces might help.
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 --- Comment #2 from Richard Biener --- We're then inlining some more costing another ~5GB ontop of the early optimization memory use of ~5GB (might be other IPA transforms than inlining as well). The big function is meanwhile 2 million basic blocks... update-SSA and friends are no fun here (the function with 2 million BBs is eval_orthob). Ah, you use [[gnu::flatten]] on that - so isn't it just what you asked for? I wonder if Clang implements that at all. Note the issue with -fvar-tracking* and -g and large functions is known...
[Bug target/95125] Unoptimal code for vectorized conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #7)
> (In reply to Uroš Bizjak from comment #6)
> > (In reply to Hongtao.liu from comment #5)
> > > (In reply to Uroš Bizjak from comment #3)
> > > > It turns out that a bunch of patterns have to be renamed (and testcases
> > > > added).
> > > >
> > > > Easyhack, waiting for someone to show some love to conversion patterns
> > > > in
> > > > sse.md.
> > >
> > > expander for floatv4siv4df2, fix_truncv4dfv4si2 already exists.
> > >
> > > if change **float_double fix_double** to
> > > ---
> > > void
> > > float_double (void)
> > > {
> > > d[0] = i[0];
> > > d[1] = i[1];
> > > d[2] = i[2];
> > > d[3] = i[3];
> > > }
> >
> > Hm, the above is vectorized, but the equivalent:
> >
> > void
> > float_double (void)
> > {
> > for (int n = 0; n < 4; n++)
> > d[n] = i[n];
> > }
> >
> > is not?
>
> Yes, we're committing to a too high VF here, likely because we pick the
> "wrong" vector mode too early. We could eventually fix this up in
> the early vectype analysis.
It might be worth investigating VECT_COMPARE_COSTS, which weighs
the cost of different VFs against each other and is how SVE copes
with this. I guess the danger is that it might interfere with
-mprefer-* options (although the first VF listed by
autovectorize_vector_modes wins in a tie).
[Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 --- Comment #1 from Richard Biener --- Confirmed. We do have (a) huuuge function here, containing 539237 basic blocks after early inlining which is void polyquad::BaseDomain::expand(const VectorXT&, polyquad::BaseDomain::MatrixPtsT&) const [with Derived = polyquad::TetDomain > >; T = boost::multiprecision::number >; int Ndim = 3; int Norbits = 5] obviously every IL walk will be bad here. Didn't yet find the actual wall it runs into, still runs...
[Bug target/95125] Unoptimal code for vectorized conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #7 from Richard Biener ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > (In reply to Uroš Bizjak from comment #3)
> > > It turns out that a bunch of patterns have to be renamed (and testcases
> > > added).
> > >
> > > Easyhack, waiting for someone to show some love to conversion patterns in
> > > sse.md.
> >
> > expander for floatv4siv4df2, fix_truncv4dfv4si2 already exists.
> >
> > if change **float_double fix_double** to
> > ---
> > void
> > float_double (void)
> > {
> > d[0] = i[0];
> > d[1] = i[1];
> > d[2] = i[2];
> > d[3] = i[3];
> > }
>
> Hm, the above is vectorized, but the equivalent:
>
> void
> float_double (void)
> {
> for (int n = 0; n < 4; n++)
> d[n] = i[n];
> }
>
> is not?
Yes, we're committing to a too high VF here, likely because we pick the
"wrong" vector mode too early. We could eventually fix this up in
the early vectype analysis.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #4 from Tobias Burnus --- See also https://gcc.gnu.org/pipermail/gcc/2020-April/thread.html#402 (for details/current status, ask those involved).
[Bug fortran/93826] [OpenMP][OpenACC] Collapsed loop – code silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826 Tobias Burnus changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- OpenMP 5 lists under changes: "The collapse of associated loops that are imperfectly nested loops was defined for the worksharing-loop (see Section 2.9.2 on page 10), simd (see Section 2.9.3.1 on page 110), taskloop (see Section 2.10.2 on page 140) and distribute (see Section 2.9.4.2 on page 123) constructs." worksharing: https://www.openmp.org/spec-html/5.0/openmpsu41.html simd:https://www.openmp.org/spec-html/5.0/openmpsu42.html taskloop:https://www.openmp.org/spec-html/5.0/openmpsu47.html distribute: https://www.openmp.org/spec-html/5.0/openmpsu43.html Both C and Fortran example compile with PGI, PGI does set the variable to "x=5". The Intel compiler rejects C + Fortran code, Clang rejects the C example. Hence: – OpenMP 4.5: * gfortran has accept-invalid+diagnostic bug - OpenMP 5: * gfortran needs to diagnose 'order(concurrent)' (once the 'order' clause is implemented) * gcc/g++/gfortran needs to handle intervening code in the other cases. - OpenACC: need to reject the code.
[Bug c++/95269] New: Lambda is allowed to capture any constexpr variable without specifying any captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95269
Bug ID: 95269
Summary: Lambda is allowed to capture any constexpr variable
without specifying any captures
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dragondreamer at live dot com
Target Milestone: ---
G++ (at least these versions: 8.2.1, 9.2.1, 10.1.0, trunk) successfully
compiles the following code:
// ===
template
constexpr void test(Lambda lambda)
{
constexpr auto result = lambda();
static_assert(result.value == 1);
}
struct teststruct
{
int value = 0;
};
constexpr auto get_value()
{
teststruct result{};
result.value = 1;
return result;
}
int main()
{
constexpr auto value = get_value();
//Here's a lambda without any captures
auto options_lambda = []() { return value; };
test(options_lambda);
}
// ===
This code instead should produce an error when trying to create a lambda which
uses "value" without capturing it. This is the exact behavior of Clang and
MSVC, which both produce an error message.
As far as I understand, the following rule must be applied here:
"If a lambda expression (or an instantiation of a generic lambda's function
call operator) ODR-uses this or any variable with automatic storage duration,
it must be captured by the lambda expression."
[Bug fortran/93826] [OpenMP][OpenACC] Collapsed loop – code silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826 --- Comment #3 from Tobias Burnus --- OpenMP 5 has: "If the *ordered* clause is present, all loops associated with the construct must be perfectly nested; that is there must be no intervening code between any two loops." (2.9.2 Worksharing-Loop Construct) For "2.10.7.1 tile Construct", OpenMP (latest draft) has: "All loops associated with the construct must be perfectly nested; that is there must be no intervening code between any two loops."
[Bug fortran/93826] [OpenMP][OpenACC] Collapsed loop – code silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826 --- Comment #2 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > do j = 1, 8 > do k = 1, 8 > end do > x = 5 ! <<< not translated but also not an error message > end do Complications: BLOCK inside the j-do loop body (only one do loop, something else; only var decl etc.); empty block(s) before/after the inner k do loop; nonempty block.
[Bug target/95125] Unoptimal code for vectorized conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
Uroš Bizjak changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #6 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Uroš Bizjak from comment #3)
> > It turns out that a bunch of patterns have to be renamed (and testcases
> > added).
> >
> > Easyhack, waiting for someone to show some love to conversion patterns in
> > sse.md.
>
> expander for floatv4siv4df2, fix_truncv4dfv4si2 already exists.
>
> if change **float_double fix_double** to
> ---
> void
> float_double (void)
> {
> d[0] = i[0];
> d[1] = i[1];
> d[2] = i[2];
> d[3] = i[3];
> }
Hm, the above is vectorized, but the equivalent:
void
float_double (void)
{
for (int n = 0; n < 4; n++)
d[n] = i[n];
}
is not?
[Bug target/95125] Unoptimal code for vectorized conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
--- Comment #5 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #3)
> It turns out that a bunch of patterns have to be renamed (and testcases
> added).
>
> Easyhack, waiting for someone to show some love to conversion patterns in
> sse.md.
expander for floatv4siv4df2, fix_truncv4dfv4si2 already exists.
if change **float_double fix_double** to
---
void
float_double (void)
{
d[0] = i[0];
d[1] = i[1];
d[2] = i[2];
d[3] = i[3];
}
void
fix_double (void)
{
i[0] = d[0];
i[1] = d[1];
i[2] = d[2];
i[3] = d[3];
}
it successfully generate
---
float_double():
vcvtdq2pd i(%rip), %ymm0
vmovapd %ymm0, d(%rip)
vzeroupper
ret
fix_double():
vcvttpd2dqy d(%rip), %xmm0
vmovdqa %xmm0, i(%rip)
ret
l:
-
Different result when executing UB programs
Hi, there!
I am new for using GCC mail list, please forgive me if something is wrong.
I have some issues about how GCC deal with the different optimizations in a
UB program.
For example,
small.cc
*#include unsigned long long a;void b(unsigned long long *c, int
h) { *c = h; }int d = 0;int main() { long e = -5392885090005969454L, f =
-7099246355752164823LL, g = f - d + e; b(, g); std::cout << a <<
std::endl;}*
Here are the instructions I used and outputs
*$g++-8 --version*
g++-8 (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*$g++-8 -O0 small.cc ; ./a.out*
18446744073174349819
*$g++-8 -O1 small.cc ; ./a.out *
0
*$g++-8 -O0 -fsanitize=undefined small.cc ; ./a.out*
small.cc:6:63: runtime error: signed integer overflow: -5392885090005969454
+ -7099246355752164823 cannot be represented in type 'long int'
18446744073174349819
*$g++-8 -O1 -fsanitize=undefined small.cc ; ./a.out*
small.cc:6:63: runtime error: signed integer overflow: -5392885090005969454
+ -7099246355752164823 cannot be represented in type 'long int'
18446744073174349819
The O2~Os produce the same results with O1. It's so weird I add
"-fsanitize=undefined" with "-O1" and produce a different result compared
to only with "-O1".
So, my concerns are
* It's a bug in GCC with the above results? Or is it a bug if GCC produces
different results in UB programs with different optimization options?
* How GCC deal with other UB programs, do GCC have any default strategy to
deal with that?
Thank you all, and any suggestions are welcome!
Best,
Haoxin
[Bug tree-optimization/95268] ICE: invalid ‘PHI’ argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95268 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-05-22 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- Mine.
[Bug target/95266] [11 regression] gcc.dg/vect/bb-slp-pr69907.c fails on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95266 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-05-22 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267 --- Comment #7 from otcmaf --- (In reply to Andrew Pinski from comment #5) > (In reply to otcmaf from comment #4) > > Do you mean that those pattern above are also wrong pattern ? > > YES those are broken. Ok, thanks very much.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Max from comment #2) > Is there anyone more familiar with GCC internals and/or the AVR backend who > I would be able to consult or possibly work with on this? I think Jeff Law mentioned on the gcc-patches mailing list that he would be willing to answer questions and assist anyone willing to work on MODE_CC conversion. So, I would ask on the list: https://gcc.gnu.org/mailman/listinfo/gcc-patches
[Bug target/95261] [11 regression] gcc.target/powerpc/pr80695-p8.c and gcc.target/powerpc/pr80695-p9.c fail starting with r11-478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95261 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2020-05-22 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |11.0 --- Comment #1 from Richard Biener --- I will have a look.
[Bug target/95255] [10/11 Regression] ICE in gen_roundevendf2, at config/i386/i386.md:16328 since r10-2809-gd3b92f35d84f44a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95255 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253 Richard Biener changed: What|Removed |Added Keywords||build Version|unknown |10.1.0 Target Milestone|--- |10.2
[Bug target/95251] x86 code size expansion inserting field into a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95251
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-05-22
Target||x86_64-*-* i?86-*-*
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||missed-optimization
--- Comment #1 from Richard Biener ---
Confirmed. We expand from
x7b00 (u64 x, u8 b)
{
struct mr D.2257;
[local count: 1073741824]:
MEM [(struct mr *) + 2B] = {};
D.2257.u.i.a = 7;
D.2257.u.i.b = b_4(D);
D.2257.x = x_6(D);
return D.2257;
it might be the zeroing intoduces the SSE usage, with -mno-sse we're not
really better though:
x7b00:
.LFB4:
.cfi_startproc
xorl%eax, %eax
movq%rdi, %rdx
movl$6, %ecx
leaq-24(%rsp), %rdi
rep stosb
movq%rsi, %rcx
movabsq $281474976710655, %rax
andq-24(%rsp), %rax
salq$16, %rax
movb$7, %al
movb%cl, %ah
ret
[Bug tree-optimization/95268] New: ICE: invalid ‘PHI’ argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95268
Bug ID: 95268
Summary: ICE: invalid ‘PHI’ argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
GCC fails with "invalid ‘PHI’ argument"
Error:
>$ g++ -O3 func.cpp -w
func.cpp: In function ‘void test()’:
func.cpp:10:6: error: invalid ‘PHI’ argument
10 | void test() {
| ^~~~
{CLOBBER}
_98 = PHI <{CLOBBER}(5), _17(7)>
during GIMPLE pass: sink
func.cpp:10:6: internal compiler error: verify_gimple failed
0x113ea11 verify_gimple_in_cfg(function*, bool)
gcc_src/gcc/tree-cfg.c:5461
0x101204f execute_function_todo
gcc_src/gcc/passes.c:1985
0x1012e2e execute_todo
gcc_src/gcc/passes.c:2039
Reproducer:
#include
extern short var_0, var_2, var_3, var_9, var_11, var_13, var_14, var_19,
var_22,
var_32, var_37, var_44, var_57, var_59, var_63, var_70;
extern unsigned var_5;
extern char var_6, var_12, var_18, var_38, var_39, var_43, var_55, var_64,
arr_35;
extern long var_7, var_8, var_10, var_15, var_25, var_56;
extern int var_21, var_36, var_51, var_65, var_68, arr_7;
extern bool var_46, var_58, var_67;
void test() {
var_12 = 0 >= 0;
var_13 = arr_7;
var_14 = (unsigned long)var_7 >> -564810131 + 564810189;
var_15 = var_5;
var_18 = -602739307623583391;
var_19 = -~0;
var_21 = var_10 >> var_8 - 17101301574577641170ULL;
var_22 = var_5;
var_25 = var_9;
var_32 = std::max((unsigned)var_2, var_5);
var_36 = 9557;
var_37 = 394545925;
var_38 = 0 >= 0;
var_39 = var_5;
var_43 = 0;
var_44 = arr_35;
var_46 = var_7;
for (short a = 0; a < 9; a = 021)
for (short b = 0; b < 024; b += 4)
var_51 = std::min((long long)(var_2 ?: var_9), (long long)var_9);
var_55 = var_0;
var_56 = 3896150587;
var_57 = var_11;
var_58 = var_59 = var_11;
var_63 = 73;
var_64 = 10393232284806619711ULL;
var_65 = var_3;
var_67 = var_6;
var_68 = var_70 = 0;
}
GCC version:
11.0.0 (149c8c7c27a17a2941d07e2f76b1e1c823e2fa80)
[Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267 zhongyunde at tom dot com changed: What|Removed |Added CC||zhongyunde at tom dot com --- Comment #6 from zhongyunde at tom dot com --- *** Bug 95210 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/95210] internal compiler error: in prepare_copy_insn, at gcse.c:1988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210 zhongyunde at tom dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from zhongyunde at tom dot com --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267 *** This bug has been marked as a duplicate of bug 95267 ***
[Bug tree-optimization/95248] [11 Regression] GCC produces incorrect code with -O3 for loops since r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95248 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/95242] [10/11 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242 Richard Biener changed: What|Removed |Added Known to work||9.3.0 Keywords||diagnostic Summary|[10 Regression] spurious|[10/11 Regression] spurious |"warning: zero as null |"warning: zero as null |pointer constant|pointer constant |[-Wzero-as-null-pointer-con |[-Wzero-as-null-pointer-con |stant]" on comparisons with |stant]" on comparisons with |-std=c++2a |-std=c++2a Target Milestone|--- |10.2
[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
--- Comment #6 from rguenther at suse dot de ---
On Thu, 21 May 2020, zhoukaipeng3 at huawei dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
>
> --- Comment #4 from Kaipeng Zhou ---
> Sorry for not expressing clearly.
>
> I have debugged the testcase you provided. Not eliminating them is not caused
> by IFN. The relevant code is in the "get_computation_aff_1" function.
>
> In IVOPTs the IV_STEPs must be checked by function "constant_multiple_of"
> before using an IV variable to eliminate the other. But if the tree_code of
> input IV_STEP is SSA_NAME, the function will return false. In your testcase,
> the tree_code of IV_STEP is MULT_EXPR, so it return true.
>
> Gimple for my testcase:
>[local count: 8589933]:
> _83 = (sizetype) inc_y_22(D);
> _84 = _83 * POLY_INT_CST [16, 16];
> _85 = (long unsigned int) inc_y_22(D);
> _86 = _85 * 8;
> _87 = (ssizetype) _86;
> _88 = _87 /[ex] 8;
> _89 = (long unsigned int) _88;
> _90 = VEC_SERIES_EXPR <0, _89>;
> vect_cst__95 = [vec_duplicate_expr] m_17(D);
> _97 = (sizetype) inc_x_20(D);
> _98 = _97 * POLY_INT_CST [16, 16];
> _99 = (long unsigned int) inc_x_20(D);
> _100 = _99 * 8;
> _101 = (ssizetype) _100;
> _102 = _101 /[ex] 8;
> _103 = (long unsigned int) _102;
> _104 = VEC_SERIES_EXPR <0, _103>;
> _109 = (sizetype) inc_x_20(D);
> _110 = _109 * POLY_INT_CST [16, 16];
> _111 = (long unsigned int) inc_x_20(D);
The issue is you have two copies of
(sizetype) inc_x_20(D) * POLY_INT_CST [16, 16];
and IVOPTs does not perform CSE. vinfo->ivexpr_map is supposed to
catch those "IV base and/or step expressions". So look where
they are inserted and check the CSE map is used. Alternatively
fixup hashing/comparing to handle POLY_INT_CST [16, 16] if that
is the reason for the missed CSE.
> _112 = _111 * 8;
> _113 = (ssizetype) _112;
> _114 = _113 /[ex] 8;
> _115 = (long unsigned int) _114;
> _116 = VEC_SERIES_EXPR <0, _115>;
> max_mask_123 = .WHILE_ULT (0, 1000, { 0, ... });
>
>[local count: 429496649]:
> # vectp_b.3_91 = PHI
> # vectp_a.7_105 = PHI
> # vectp_a.11_117 = PHI
> # ivtmp_120 = PHI
> # loop_mask_93 = PHI
> vect__4.5_94 = .MASK_GATHER_LOAD (vectp_b.3_91, _90, 8, { 0.0, ... },
> loop_mask_93);
> vect__5.6_96 = vect__4.5_94 * vect_cst__95;
> vect__9.9_107 = .MASK_GATHER_LOAD (vectp_a.7_105, _104, 8, { 0.0, ... },
> loop_mask_93);
> vect__10.10_108 = vect__5.6_96 + vect__9.9_107;
> .MASK_SCATTER_STORE (vectp_a.11_117, _116, 8, vect__10.10_108,
> loop_mask_93);
> vectp_b.3_92 = vectp_b.3_91 + _84;
> vectp_a.7_106 = vectp_a.7_105 + _98;
> vectp_a.11_118 = vectp_a.11_117 + _110;
> ivtmp_121 = ivtmp_120 + POLY_INT_CST [2, 2];
> _122 = (unsigned int) ivtmp_121;
> next_mask_124 = .WHILE_ULT (_122, 1000, { 0, ... });
> if (next_mask_124 != { 0, ... })
> goto ; [98.00%]
> else
> goto ; [2.00%]
>
> _98 and _110 are IV_STEPs. They are both SSA_NAME, so they cannot currently
> be
> eliminated in IVOPTs.
>
> I am not sure about my opinion. If wrong, please correct me. And can you
> provide some suggestions on how to solve this problem? Should I try to
> enhance
> the "constant_multiple_of" function?
>
>
