[Bug ipa/100513] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

--- Comment #6 from Jiu Fu Guo  ---
cut..
> 0xa5a5a5a5a5a5a5a means the location has been GC'ed already; either from
> ggc_free or from a previous ggc_collect.
> What you can try is run with the following options:
> --param ggc-min-expand=1 --param ggc-min-heapsize=1
> Which will cause ggc_collect to run the garbage collection almost every time
> (setting it to 0 will run it every time but it is much much slower) and
> reduce the testcase that way.

Hi Andrew, thanks.

With --param ggc-min-expand=1 --param ggc-min-heapsize=1, the error can
reproduced too.

> 
> Also it would be a good idea to attach the preprocessed source and the exact
> command line xgcc is involved and which stage is this at too and the full
> configure command line used.

I would continue to reduce the testcase, .ii file is still large.

> 
> I highly doubt it is related to PR 99447 which is about a stack overflow
> while doing the garbage collection walk.
Yes, it is possible! The stack depth is big: > 500 levels at least.

[Bug ipa/100513] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

--- Comment #5 from Jiu Fu Guo  ---
build command is:
configure --enable-languages=c,c++,fortran,objc,obj-c++,go --with-cpu=native
--disable-multilib --with-long-double-128 --prefix=$HOME/xx
--with-build-config=bootstrap-O3
make -j

[Bug ipa/100513] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

--- Comment #4 from Jiu Fu Guo  ---
Created attachment 50787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50787=edit
t.ii

/home/guojiufu/gcc/build/gcc-mainline-test/./prev-gcc/xg++
-B/home/guojiufu/gcc/build/gcc-mainline-test/./prev-gcc/   -c   -O3  -o
tree-cfg.o 
t.ii

[Bug tree-optimization/100511] Fail to remove dead code in loop

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100511

--- Comment #3 from Andrew Pinski  ---
(In reply to Jiangning Liu from comment #2)
> Then why gcc can't optimize this case either? sizeof (XX) <> sizeof(g) here.

The second case is a VRP issue which really should be filed seperately.

-O3 case is better than -O2 for sure.
ldr w2, [x1]
cmp w2, w0
beq L6
...
ret
L6:
mov w1, 0
.p2align 3,,7
L3:
add w1, w1, 1
cmp w0, w1
beq L12 ; loop exit 1
cmp w2, w1
bge L3; should be always true
; loop exit 2/print unreachable

-O2 seems like a mess:
L6:
mov w4, w0
add w0, w0, 1
mov w3, 1
cmp w1, w0
beq L16; loop exit
L5:
cmp w2, w1
bne L6 ; loop back
cmp w2, w0
blt L17; loop exit
add w0, w0, 1
mov w4, 2
mov w3, 1
cmp w1, w0
bne L5 ; loop back
; loop exit
; print


Note in either cases, clang 12 does not remove the condition.

[Bug jit/64949] jit linking fails when building with in-tree libraries (mpc etc...)

[yumeyao at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64949

YumeYao  changed:

   What|Removed |Added

 CC||yumeyao at gmail dot com

--- Comment #2 from YumeYao  ---
A simple fix is just changing "--disable-shared" within
configure-stageN-{hostlib} sections to "--disable-shared --with-fpic" in
top-level Makefile.in.

But this is not always wanted. A better approach is supposed to check if
"--with-fpic" is necessary before appending it. For example,
"--enable-languages=jit" turns it on, maybe there're other cases where it
should be turned on.

[Bug bootstrap/100506] bootstrap error: No rule to make target 'gcc/version.c', needed by 'ada/stamp-sdefault'.

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100506

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
*** Bug 100514 has been marked as a duplicate of this bug. ***

[Bug ada/100514] [12 regression] Error in Ada build in bootstrap after r12-648

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100514

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Already fixed.

*** This bug has been marked as a duplicate of bug 100506 ***

[Bug tree-optimization/100511] Fail to remove dead code in loop

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100511

--- Comment #2 from Jiangning Liu  ---
Then why gcc can't optimize this case either? sizeof (XX) <> sizeof(g) here.

#include 

int a;
typedef struct {
int b;
int count;
} XX;

int g;

__attribute__((noinline)) void f(XX *x)
{
int c1 = 0;
int c3 = a;
if (x)
c1 = x->count;
for (int i=0; icount) {
if (i > c3) {
printf("Unreachable!");
break;
}
else
g = 2;
} else
g = i;
}
}

void main(void)
{
XX x;
x.count = 100;
a = 100;
f();
}

[Bug ada/100514] New: [12 regression] Error in Ada build in bootstrap after r12-648

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100514

Bug ID: 100514
   Summary: [12 regression] Error in Ada build in bootstrap after
r12-648
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:e3a682f4197f9f39808febfd1862e722d7675d34, r12-648

Removing version.c broke the ada build:

configure with languages=all

make
. . .
make[3]: *** No rule to make target
'/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/version.c', needed by
'ada/stamp-sdefault'.  Stop.
make[3]: Leaving directory '/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc'

[Bug ipa/100513] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

--- Comment #3 from Andrew Pinski  ---
(In reply to Jiu Fu Guo from comment #1)
> The error is raised after ipa “inlining” pass, when doing ggc_collect at
> stage 2.
> 
> At code:
> xlimit = ((*xlimit).next);
> 
> The value of xlimit becomes 0xa5a5a5a5a5a5a5a5 before crash. 0xa5 may comes
> from poison_pages.
> 
> 
> If using "-fno-inline" the crash disappears.

0xa5a5a5a5a5a5a5a means the location has been GC'ed already; either from
ggc_free or from a previous ggc_collect.
What you can try is run with the following options:
--param ggc-min-expand=1 --param ggc-min-heapsize=1
Which will cause ggc_collect to run the garbage collection almost every time
(setting it to 0 will run it every time but it is much much slower) and reduce
the testcase that way.

Also it would be a good idea to attach the preprocessed source and the exact
command line xgcc is involved and which stage is this at too and the full
configure command line used.

I highly doubt it is related to PR 99447 which is about a stack overflow while
doing the garbage collection walk.

[Bug tree-optimization/100511] Fail to remove dead code in loop

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100511

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias, missed-optimization
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
So this is only because sizeof (XX) == sizeof(g) .
That is if you add a field to XX, it works correctly.

I susepct this is due to handling int can alias the access to count.

I will let someone else who understands GCC's aliasing is this is a valid thing
to optimize or not.

[Bug tree-optimization/100512] [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os)

[haoxintu at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512

--- Comment #1 from Haoxin Tu  ---

(In reply to Haoxin Tu from comment #0)

> $gcc -w -O2 

Sorry, it's an incomplete command here. It should be "gcc -w -O2 small.c".

[Bug ipa/100513] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

--- Comment #2 from Jiu Fu Guo  ---
There is a similar bug fixed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447.  it may be a different
issue.

[Bug ipa/100513] ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

--- Comment #1 from Jiu Fu Guo  ---
The error is raised after ipa “inlining” pass, when doing ggc_collect at stage
2.

At code:
xlimit = ((*xlimit).next);

The value of xlimit becomes 0xa5a5a5a5a5a5a5a5 before crash. 0xa5 may comes
from poison_pages.


If using "-fno-inline" the crash disappears.

[Bug ipa/100513] New: ICE: Segmentation fault (in lookup_page_table_entry) for bootstrap-O3

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100513

Bug ID: 100513
   Summary: ICE: Segmentation fault (in lookup_page_table_entry)
for bootstrap-O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

With --with-build-config=bootstrap-O3, I encounter an ICE in bootstrap on
ppc64le:

/home/guojiufu/gcc/gcc-mainline-test/gcc/tree-cfg.c: In function 'tree_node*
get_cases_for_edge(edge, gswitch*)':
/home/guojiufu/gcc/gcc-mainline-test/gcc/tree-cfg.c:1339:1: internal compiler
error: Segmentation fault
 1339 | }
   | ^
0x116b928b crash_signal
/home/guojiufu/gcc/gcc-mainline-test/gcc/toplev.c:327
0x10c6f55c lookup_page_table_entry
/home/guojiufu/gcc/gcc-mainline-test/gcc/ggc-page.c:630
0x10c71057 ggc_set_mark(void const*)
/home/guojiufu/gcc/gcc-mainline-test/gcc/ggc-page.c:1544
0x11175ddf gt_ggc_mx_basic_block_def(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1518
0x11174a5f gt_ggc_mx_gimple(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1238
0x10af4757 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:483
0x11174a2b gt_ggc_mx_gimple(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1235
0x111756f3 gt_ggc_mx_cgraph_edge(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1403
0x111756d3 gt_ggc_mx_cgraph_edge(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1402
0x111751e7 gt_ggc_mx_symtab_node(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1348
0x10af3c37 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:346
0x11176ff3 gt_ggc_mx(tree_node*&)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1790
0x10b03e7b void gt_ggc_mx(vec*)
/home/guojiufu/gcc/gcc-mainline-test/gcc/vec.h:1353
0x11177477 gt_ggc_mx_vec_tree_va_gc_(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1868
0x10af1f53 gt_ggc_mx_lang_type(void*)
./gt-cp-tree.h:36
0x10af4457 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:440
0x10af32ef gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:263
0x11176ff3 gt_ggc_mx(tree_node*&)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1790
0x10b03e7b void gt_ggc_mx(vec*)
/home/guojiufu/gcc/gcc-mainline-test/gcc/vec.h:1353
0x11177477 gt_ggc_mx_vec_tree_va_gc_(void*)
/home/guojiufu/gcc/build/gcc-mainline-test/gcc/gtype-desc.c:1868
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:1142: recipe for target 'tree-cfg.o' failed

[Bug tree-optimization/100512] New: [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os)

[haoxintu at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512

Bug ID: 100512
   Summary: [12 Regression] ICE during GIMPLE pass: cddce in
mark_operand_necessary, at tree-ssa-dce.c:173  (under
-O2 to -Os)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi all.

$cat small.c
#include 
int a;
void b() {
  int16_t *c;
  uint16_t d = 2;
  if (0 == d) {
uint64_t e;
uint64_t *f = 
for (;;) {
  if (e += 0 >= 0)
for (;;)
  ;
g:
  for (; a;) {
int16_t i = 
*c = i && *f;
  }
}
  }
  goto g;
}


$gcc -w -O2 
during GIMPLE pass: cddce
small.c: In function ‘b’:
small.c:21:1: internal compiler error: in mark_operand_necessary, at
tree-ssa-dce.c:173
   21 | }
  | ^
0x65b30e mark_operand_necessary
../../gcc/tree-ssa-dce.c:173
0xc86d76 propagate_necessity
../../gcc/tree-ssa-dce.c:852
0xc86d76 perform_tree_ssa_dce
../../gcc/tree-ssa-dce.c:1673
0xc887d5 tree_ssa_cd_dce
../../gcc/tree-ssa-dce.c:1717
0xc887d5 execute
../../gcc/tree-ssa-dce.c:1789
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
tuhaoxin@oscar-2020:~/dut-research/covsmith-test/20210502$ cat small.c
#include 
int a;
void b() {
  int16_t *c;
  uint16_t d = 2;
  if (0 == d) {
uint64_t e;
uint64_t *f = 
for (;;) {
  if (e += 0 >= 0)
for (;;)
  ;
g:
  for (; a;) {
int16_t i = 
*c = i && *f;
  }
}
  }
  goto g;
}

$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/tuhaoxin/compilers/gcc/build/
--enable-bootstrap --enable-checking=release --enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) (GCC) 

This crash only exists in the current trunk version of GCC, and the released
versions perform well. I also tested it on an earlier GCC trunk built on
20210425, it does not crash as well. So I think it's a regression issue in
GCC-12.


Thanks,
Haoxin

[Bug tree-optimization/100511] New: Fail to remove dead code in loop

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100511

Bug ID: 100511
   Summary: Fail to remove dead code in loop
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangning.liu at amperecomputing dot com
  Target Milestone: ---

For this simple case, gcc doesn't know the if condition (i > c2) is always
false.

#include 

typedef struct {
int count;
} XX;

int g;

__attribute__((noinline)) void f(XX *x)
{
int c1 = 0;
if (x)
c1 = x->count;
for (int i=0; icount;
if (i > c2) {
printf("Unreachable!");
break;
}
else
g = i;
}
}

void main(void)
{
XX x;
x.count = 100;
f();
}

If we change variable the type of variable g to float, gcc does optimize away
this if condition inside the loop, so why alias analysis can't recognize g is
different from x->count?

[Bug c++/51577] dependent name lookup finds operator in global namespace

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:6ab1176667734bd6de20833f8d263c03a418c452

commit r12-702-g6ab1176667734bd6de20833f8d263c03a418c452
Author: Patrick Palka 
Date:   Mon May 10 22:38:34 2021 -0400

c++: dependent operator expression lookup [PR51577]

This unconditionally enables the maybe_save_operator_binding mechanism
for all function templates, so that when resolving a dependent operator
expression from a function template we ignore later-declared
namespace-scope bindings that weren't visible at template definition
time.  This patch additionally makes the mechanism apply to dependent
comma and compound-assignment operator expressions.

Note that this doesn't fix the testcases in PR83035 or PR99692 because
there the dependent operator expressions aren't at function scope.  I'm
not sure how adapt this mechanism for these testcases, since although
we'll in both testcases have a TEMPLATE_DECL to associate the lookup
result with, at instantiation time we won't have an appropriate binding
level to push to.

gcc/cp/ChangeLog:

PR c++/51577
* name-lookup.c (maybe_save_operator_binding): Unconditionally
enable for all function templates, not just generic lambdas.
Handle compound-assignment operator expressions.
* typeck.c (build_x_compound_expr): Call
maybe_save_operator_binding
in the type-dependent case.
(build_x_modify_expr): Likewise.  Move declaration of 'op' closer
to its first use.

gcc/testsuite/ChangeLog:

PR c++/51577
* g++.dg/lookup/operator-3.C: New test.

[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:e7a9f085ffd34b0d7bc4b803c182b41494f609aa

commit r12-701-ge7a9f085ffd34b0d7bc4b803c182b41494f609aa
Author: Patrick Palka 
Date:   Mon May 10 22:33:04 2021 -0400

c++: fn parm pack expansion inside constraint [PR100138]

This PR is about CTAD but the underlying problems are more general;
CTAD is a good trigger for them because of the necessary substitution
into constraints that deduction guide generation entails.

In the testcase below, when generating the implicit deduction guide for
the constrained constructor template for A, we substitute the generic
flattening map 'tsubst_args' into the constructor's constraints.  During
this substitution, tsubst_pack_expansion returns a rebuilt pack
expansion for sizeof...(xs), but doesn't carry over the
PACK_EXPANSION_LOCAL_P (and PACK_EXPANSION_SIZEOF_P) flag from the
original tree to the rebuilt one.  The flag is otherwise unset on the
original tree but gets set for the rebuilt tree from make_pack_expansion
since at_function_scope_p() is true (we're inside main).  This leads to
a crash during satisfaction when substituting into the pack expansion
because we don't have local_specializations set up (and it'd be set up
for us if PACK_EXPANSION_LOCAL_P is unset)

Similarly, tsubst_constraint needs to set cp_unevaluated so that the
substitution performed therein doesn't rely on local_specializations.
This avoids a crash during CTAD for C below.

gcc/cp/ChangeLog:

PR c++/100138
* constraint.cc (tsubst_constraint): Set up cp_unevaluated.
(satisfy_atom): Set up iloc_sentinel before calling
cxx_constant_value.
* pt.c (tsubst_pack_expansion): When returning a rebuilt pack
expansion, carry over PACK_EXPANSION_LOCAL_P and
PACK_EXPANSION_SIZEOF_P from the original pack expansion.

gcc/testsuite/ChangeLog:

PR c++/100138
* g++.dg/cpp2a/concepts-ctad4.C: New test.

[Bug bootstrap/100506] bootstrap error: No rule to make target 'gcc/version.c', needed by 'ada/stamp-sdefault'.

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100506

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
.

[Bug bootstrap/100506] bootstrap error: No rule to make target 'gcc/version.c', needed by 'ada/stamp-sdefault'.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100506

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:0c54d25a7686406a11f44f58261a9e63821022b7

commit r12-699-g0c54d25a7686406a11f44f58261a9e63821022b7
Author: Martin Liska 
Date:   Tue May 11 00:44:25 2021 +0200

Fix missing version_string in Ada

gcc/ada/
PR bootstrap/100506
* Make-generated.in: Replace version.c with ada/version.c.
* gcc-interface/Make-lang.in: Add version.o to GNAT1_C_OBJS.
Add version.o to GNAT_ADA_OBJS and GNATBIND_OBJS.
* gcc-interface/Makefile.in: Add version.o to TOOLS_LIBS.
* gnatvsn.adb: Start using a new C symbol gnat_version_string.
* version.c: New file.

[Bug middle-end/100477] Bogus -Wstringop-overflow warning on memset

[andysem at mail dot ru via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477

--- Comment #7 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #6)
> In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes.  This is
> necessary so that the difference between the address of its first byte and
> that just past its last byte fits in ptrdiff_t.

Sure, but memset, as well as other string operations, takes size_t as an
argument and doesn't have this limitation. They must be able to operate on the
full range of size_t worth of bytes. I don't remember neither C nor C++
declaring a narrowing limit on the allowed size_t range wrt. these functions.

And please note that string functions are often used on raw storage that is
obtained through means other than defined by C++ as operations creating
objects. That storage may be larger than the maximum C++ object size.

> A number of GCC warnings
> point out code that breaks this assumption, including allocations in excess
> of the maximum or calls to functions like memset or memcpy that would access
> more than the maximum.   None of these warnings considers the conditions
> that must be true in order for control to reach the problem statement, so if
> the statement hasn't been eliminated from in the IL (i.e., can be seen in
> the output of -fdump-tree-optimized or whatever pass the warning runs in)
> the warning triggers.  Taking the conditions into consideration and issuing
> "maybe" kinds of warnings (like -Wmaybe-uninitialized) is a work in progress
> but as of now no warning other thanb -Wmaybe-uninitialized does.

Ok, then please consider this bug as a case for adding consideration of
conditions.

> No such distinction as "there's definitely a bug" vs "there may be a bug" is
> feasible because there is, in general, no way to identify functions that are
> defined but never called, or those that are only called with arguments that
> make certain code paths unreachable.  As a result, with few exceptions every
> GCC warning is of the latter kind.

To clarify, what I mean by "there's definitely a bug" kind of warning is when
the compiler has enough data to prove that the operation will result in UB (for
example, cause a buffer overflow). Such as:

char* alloc_string(size_t n)
{
char* p = new char[n]; // forgot about the byte for the terminating 0
std::memset(p, 0, n + 1);
return p;
}

This is notably different from compiler trying to reason about a possible value
of n based on size_t range and issuing warnings based on that. I would like to
see warnings of the former kind but not so much of the latter kind.

If there is no way to separate the two kinds of warnings, and the compiler does
not consider prior conditions that are written *specifically* to prevent UB
that triggers the warning, I'm afraid, I don't see the use for such warnings.

> If you're interested, the following
> two-part article discusses some of the challenges in this area:
> 
> https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings/
> https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings-
> part-2/

Thanks, I will read it. I understand that compiler warnings are not easy to
implement right.

> If the #pragma suppression doesn't work with LTO please report that as a
> separate bug.  There's nothing we can do to avoid the warning in this case.

The fact that pragmas don't work with LTO is documented in the -flto
description[1]. My impression is that gcc simply doesn't support warning
control through pragmas when LTO is enabled. Is this not the case?

I can create a bug, but I cannot provide a small repro, since the warning
triggers in a large code base, but not necessarily a small test case. Would
such a bug report be useful?

[1]: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto

[Bug target/100108] [10 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Segher Boessenkool  ---
Fixed on GCC 10 and later.  Closing.

[Bug target/100108] [10 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:5f665c1ca452673e9812cd92b07bd31441c0ac5b

commit r10-9814-g5f665c1ca452673e9812cd92b07bd31441c0ac5b
Author: Segher Boessenkool 
Date:   Tue Apr 20 12:00:50 2021 +

rs6000: Fix cpu selection w/ isel (PR100108)

There are various non-IBM CPUs with isel as well, so it is easiest if we
just don't consider that flag here (it is not needed).

2021-04-20  Segher Boessenkool  

PR target/100108
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not
consider
OPTION_MASK_ISEL.

(cherry picked from commit 6156df483fa50a08f561b6c248819f2992aa380d)

[Bug middle-end/100477] Bogus -Wstringop-overflow warning on memset

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477

--- Comment #6 from Martin Sebor  ---
In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes.  This is
necessary so that the difference between the address of its first byte and that
just past its last byte fits in ptrdiff_t.  A number of GCC warnings point out
code that breaks this assumption, including allocations in excess of the
maximum or calls to functions like memset or memcpy that would access more than
the maximum.   None of these warnings considers the conditions that must be
true in order for control to reach the problem statement, so if the statement
hasn't been eliminated from in the IL (i.e., can be seen in the output of
-fdump-tree-optimized or whatever pass the warning runs in) the warning
triggers.  Taking the conditions into consideration and issuing "maybe" kinds
of warnings (like -Wmaybe-uninitialized) is a work in progress but as of now no
warning other thanb -Wmaybe-uninitialized does.

No such distinction as "there's definitely a bug" vs "there may be a bug" is
feasible because there is, in general, no way to identify functions that are
defined but never called, or those that are only called with arguments that
make certain code paths unreachable.  As a result, with few exceptions every
GCC warning is of the latter kind.  If you're interested, the following
two-part article discusses some of the challenges in this area:

https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings/
https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings-part-2/

If the #pragma suppression doesn't work with LTO please report that as a
separate bug.  There's nothing we can do to avoid the warning in this case.

[Bug tree-optimization/100417] False positive -Wmaybe-uninitalized with malloc.

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100417

Martin Sebor  changed:

   What|Removed |Added

 CC||jochen447 at concept dot de

--- Comment #5 from Martin Sebor  ---
*** Bug 100496 has been marked as a duplicate of this bug. ***

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 100496, which changed state.

Bug 100496 Summary: False positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100496

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c/100496] False positive with -Wmaybe-uninitialized

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100496

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Sebor  ---
Yes, this is the same as pr100417.  Until something better is available a
workaround is to set the element whose address is passed to the const pointer,
like so:

extern void XmlUtf8Convert(char* p_start, const char* const p_end);

void findEncoding() {
  char buf[128];
  char *p = buf;
  buf[sizeof buf - 1] = 0;   // avoid -Wmaybe-uninitialized below
  XmlUtf8Convert(p, p + sizeof(buf) - 1);
}

Another alternative is to add an optimizer barrier (asm volatile("": :
:"memory")).

*** This bug has been marked as a duplicate of bug 100417 ***

[Bug tree-optimization/100509] ICE at -O3: in fold_convert_loc with variable (attribute) alias of different types

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100509

--- Comment #1 from Andrew Pinski  ---
(In reply to Chengnian Sun from comment #0)
> Not sure whether this is a dup of PR96131.

It is unrelated.

[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3

[tromey at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #6 from Tom Tromey  ---
(In reply to Richard Biener from comment #1)
> I commented on the gdb issue, since -flto/-fno-lto have comparable
> .debug_macro the issue must lie with gdb.  Sorry for just shifting the blame
> ;)

If you look at "readelf --debug-dump=macro" on that file, the results
are very strange.
For example, one of the CUs in the macro section does this:

 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file

... a total of 108 times.  In one spot it does this 3 times in
a sequence.  That doesn't seem right, or even useful, to me.

[Bug ada/100486] Ada build fails for 32bit Windows

[ofv at wanadoo dot es via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

ofv at wanadoo dot es changed:

   What|Removed |Added

 CC||ofv at wanadoo dot es

--- Comment #2 from ofv at wanadoo dot es ---
IIUC the problem consists on the compiler crashing, so no "error message from
the compiler".

You can see the full build output here:

https://github.com/msys2/MINGW-packages/pull/8320/checks?check_run_id=2534098704

As for the configure line, it is not shown on the build output, I'll try to get
it from elsewhere. Meanwhile, you can look at the relevant point of the build
script here:

https://github.com/msys2/MINGW-packages/blob/134b37fb4bc9b395615cfdf701aeb0635c54fa1a/mingw-w64-gcc/PKGBUILD#L197

[Bug libstdc++/100444] std::random_device isn't random on AMD

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444

--- Comment #11 from Jonathan Wakely  ---
We could use a different function for AMD, rather than __x86_rdrand. If it
reads a -1 value it could try again a few more times, and if it gets -1 every
time assume it's broken (and throw?), maybe after being suspended. If it
doesn't get -1 every time, it was a real -1 value, return that -1 (not the next
values that were read, because otherwise we would never be able to return -1).

[Bug middle-end/100425] missing -Walloca-larger-than with -O0

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100425

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/100510] bogus -Wvla-large-than with -Walloca

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100510

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||diagnostic
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Patch committed in r12-690.

[Bug tree-optimization/100510] bogus -Wvla-large-than with -Walloca

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100510
Bug 100510 depends on bug 100425, which changed state.

Bug 100425 Summary: missing -Walloca-larger-than with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100425

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/100425] missing -Walloca-larger-than with -O0

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100425

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
   Keywords||patch
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Patch (https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569571.html)
committed in r12-690.

[Bug middle-end/100425] missing -Walloca-larger-than with -O0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100425

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:f974b54b8a0c330e9dd2b43ebc940100d601df0f

commit r12-690-gf974b54b8a0c330e9dd2b43ebc940100d601df0f
Author: Martin Sebor 
Date:   Mon May 10 14:00:04 2021 -0600

Avoid -Walloca-larger-than and -Wvla-larger-than false postives and
negatives.

Resolves:
PR middle-end/100425 - missing -Walloca-larger-than with -O0
PR middle-end/100510 - bogus -Wvla-large-than with -Walloca

gcc/ChangeLog:

PR middle-end/100425
PR middle-end/100510
* gimple-ssa-warn-alloca.c (pass_walloca::firast_time_p): Rename...
(pass_walloca::xlimit_certain_p): ...to this.
(pass_walloca::gate): Execute for any kind of handled warning.
(pass_walloca::execute): Avoid issuing "maybe" and "unbounded"
warnings when xlimit_certain_p is set.

gcc/testsuite/ChangeLog:

PR middle-end/100425
PR middle-end/100510
* c-c++-common/Walloca-larger-than.C: New test.
* gcc.dg/Walloca-larger-than-4.c: New test.
* gcc.dg/Wvla-larger-than-5.c: New test.
* gcc.dg/pr79972.c: Remove unexpected warning directive.

[Bug tree-optimization/100510] bogus -Wvla-large-than with -Walloca

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100510

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:f974b54b8a0c330e9dd2b43ebc940100d601df0f

commit r12-690-gf974b54b8a0c330e9dd2b43ebc940100d601df0f
Author: Martin Sebor 
Date:   Mon May 10 14:00:04 2021 -0600

Avoid -Walloca-larger-than and -Wvla-larger-than false postives and
negatives.

Resolves:
PR middle-end/100425 - missing -Walloca-larger-than with -O0
PR middle-end/100510 - bogus -Wvla-large-than with -Walloca

gcc/ChangeLog:

PR middle-end/100425
PR middle-end/100510
* gimple-ssa-warn-alloca.c (pass_walloca::firast_time_p): Rename...
(pass_walloca::xlimit_certain_p): ...to this.
(pass_walloca::gate): Execute for any kind of handled warning.
(pass_walloca::execute): Avoid issuing "maybe" and "unbounded"
warnings when xlimit_certain_p is set.

gcc/testsuite/ChangeLog:

PR middle-end/100425
PR middle-end/100510
* c-c++-common/Walloca-larger-than.C: New test.
* gcc.dg/Walloca-larger-than-4.c: New test.
* gcc.dg/Wvla-larger-than-5.c: New test.
* gcc.dg/pr79972.c: Remove unexpected warning directive.

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #8 from Tobias Burnus  ---
I am wondering whether it has something to do with shfl now requiring .sync,
especially for sm_70. (Non-sync version was deprecated in ISA 6.0 and for sm_70
removed in ISA 6.4.)
Cross ref: PR96005.

[Bug tree-optimization/100510] bogus -Wvla-large-than with -Walloca

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100510

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Depends on||100425
   Last reconfirmed||2021-05-10
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Sebor  ---
The patch for pr100425 also fixes this.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100425
[Bug 100425] missing -Walloca-larger-than with -O0

[Bug tree-optimization/100510] New: bogus -Wvla-large-than with -Walloca

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100510

Bug ID: 100510
   Summary: bogus -Wvla-large-than with -Walloca
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The VLA below is at most 32 bytes large but with both -Walloca and
-Wvla-larger-than= GCC issues a -Wvla-larger-than false positive, both with and
without optimization.

$ cat a.c && gcc -Walloca  -S -Wvla-larger-than=1000 a.c
void f (void*);

void g (__SIZE_TYPE__ n)
{
  if (n > 32)
return;

  char a[n];
  f (a);
}

a.c: In function ‘g’:
a.c:8:8: warning: unbounded use of variable-length array [-Wvla-larger-than=]
8 |   char a[n];
  |^

[Bug c/100509] New: ICE at -O3: in fold_convert_loc, at fold-const.c:2552

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100509

Bug ID: 100509
   Summary: ICE at -O3: in fold_convert_loc, at fold-const.c:2552
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

Not sure whether this is a dup of PR96131.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) [master revision
:fb3a8fb4a:25f9f35a85ffee808fc1482b14d91176df59751b] (GCC)

$ cat mutant.c
struct X {
  int a;
};
const a = 0;
static struct X A __attribute__((alias("a")));
foo() { struct X b = A; }

$ gcc-trunk -O3 mutant.c
mutant.c:4:7: warning: type defaults to ‘int’ in declaration of ‘a’
[-Wimplicit-int]
4 | const a = 0;
  |   ^
mutant.c:6:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
6 | foo() { struct X b = A; }
  | ^~~
during GIMPLE pass: forwprop
mutant.c: In function ‘foo’:
mutant.c:6:16: internal compiler error: in fold_convert_loc, at
fold-const.c:2552
6 | foo() { struct X b = A; }
  |^
0x6bd7c1 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/fold-const.c:2552
0xc02486 fold_stmt_1
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimple-fold.c:6269
0x1032191 execute
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree-ssa-forwprop.c:3108
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c/100508] New: ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100508

Bug ID: 100508
   Summary: ICE with '-g -O3': in expand_debug_locations, at
cfgexpand.c:5618
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) [master revision
:fb3a8fb4a:25f9f35a85ffee808fc1482b14d91176df59751b] (GCC)

$ cat mutant.c
typedef __attribute__((__vector_size__(32))) V;
V j;
__attribute__((simd)) foo() { V m = j; }

$ gcc-trunk -g -O3 mutant.c
mutant.c:1:46: warning: type defaults to ‘int’ in declaration of ‘V’
[-Wimplicit-int]
1 | typedef __attribute__((__vector_size__(32))) V;
  |  ^
mutant.c:3:23: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | __attribute__((simd)) foo() { V m = j; }
  |   ^~~
during RTL pass: expand
mutant.c: In function ‘foo.simdclone.2’:
mutant.c:3:23: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5618
0x68c497 expand_debug_locations
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cfgexpand.c:5618
0x68c497 execute
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cfgexpand.c:6735
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug bootstrap/100506] bootstrap error: No rule to make target 'gcc/version.c', needed by 'ada/stamp-sdefault'.

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100506

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-05-10

--- Comment #2 from Martin Liška  ---
Yes, working on that right now.

[Bug c/100496] False positive with -Wmaybe-uninitialized

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100496

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||100417

--- Comment #1 from Andrew Pinski  ---
I think this is similar to PR 100417.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100417
[Bug 100417] False positive -Wmaybe-uninitalized with malloc.

[Bug c++/100507] [10/11/12 Regression] ICE on invalid: tree check expects tree that contains 'decl common'

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100507

Jakub Jelinek  changed:

   What|Removed |Added

Summary|ICE on invalid: tree check  |[10/11/12 Regression] ICE
   |expects tree that contains  |on invalid: tree check
   |'decl common'   |expects tree that contains
   ||'decl common'
   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
   Last reconfirmed||2021-05-10
 Ever confirmed|0   |1
   Target Milestone|--- |10.4
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[vries at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

Tom de Vries  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #7 from Tom de Vries  ---
(In reply to Tobias Burnus from comment #6)
> * Failing:
>   TITAN V| NVIDIA-SMI 455.23.05 Driver Version: 455.23.05 CUDA Version:
> 11.1

Volta.

>   Tesla V100-SXM2...| NVIDIA-SMI 410.79 Driver Version: 410.79 CUDA
> Version: 10.0

Volta.

>   Quadro GV100  | NVIDIA-SMI 460.32.03  Driver Version: 460.32.03  CUDA
> Version: 11.2

and Volta.

I don't have a volta card, unfortunately.

[Bug middle-end/100477] Bogus -Wstringop-overflow warning on memset

[andysem at mail dot ru via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477

--- Comment #5 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #4)
> The case of _size being very large and n very small may be handled correctly
> by the original code thanks to the check for _capacity but because its value
> isn't known it affects neither the codegen nor the warning.
> 
> The warning is designed to flag bounds greater than PTRDIFF_MAX

But sizes above PTRDIFF_MAX are valid sizes. IMHO, triggering the warning based
on possible sizes is just not the right approach to begin with. If what you're
trying to detect is an integral overflow then *that* is what should be
detected, and pointed to by the warning, not the unrelated memset.

As an illustration to my point, I worked around this warning by replacing
memset with std::fill_n with no other changes to the code. The optimizer will
likely convert it to memset anyway. This shows that (1) if the supposed bug is
an overflow in `_size + 4` then it is no longer being detected and (2) there is
no problem in filling more than PTRDIFF_MAX bytes (as expected, of course).

> and that's
> just what it sees here as is evident from the output of the
> -fdump-tree-optimized option.  There is nothing to fix here.  Code that's
> unreachable as a result of preconditions GCC cannot prove may be susceptible
> to false positives.  That's a problem shared by all flow-sensitive warnings,
> not just in GCC but in all static analyzers with flow analysis.
> 
> In general, GCC warnings are designed to "report constructions that are not
> inherently erroneous but that are risky or suggest there may have been an
> error."  Not every instance of every warning necessarily corresponds to an
> error, and some may even be false positives.

False positives is a very good reason for the warnings to be disabled or
ignored, meaning that they are useless.

Is there any reliable detection implemented in -Wstringop-overflow? Meaning
that, when the compiler can tell "there's definitely a bug", as opposed to
"there may be something fishy going on"? If yes, then it may be sensible to
separate the reliable and speculative parts into different warnings.
Personally, I would like to have a warning when the compiler is certain that
something is wrong, but not the false positives, like shown in this bug. That's
the only thing stopping me from just disabling this warning globally.

> Unhelpful warnings can be
> disabled either globally, on the command line, or on a case by case basis by
> #pragma GCC diagnostic.

#pragma GCC diagnostic doesn't work with LTO. I was actually suppressing that
warning in the real code base with a #pragma, but it no longer works when LTO
is enabled by default in my distro.

> Adding preconditions like 'if (_size >= __PTRDIFF_MAX__ / 4)
> __builtin_unreachable ();' (the 4 should be replaced by sizeof (value_type)
> in the original test case) often helps not just warnings but also codegen. 
> They're not required but can be helpful and preferable to suppression.

Again, that precondition is incorrect.

[Bug tree-optimization/100299] [11/12 Regression] cc1plus taking all RAM in EVRP

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100299

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
Changing component, then.

[Bug tree-optimization/100503] A possible divide by zero problem in function do_rpo_vn

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100503

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Andrew Pinski  ---
There will always be at least one BB which has its BB_EXECUTABLE set.
As shown by (on line 7610):
  entry->dest->flags |= BB_EXECUTABLE;

It is hard to do this kind of static anlysis without understanding the code
fully.

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #6 from Tobias Burnus  ---
(In reply to Tom de Vries from comment #5)
> Does it pass with GOMP_NVPTX_JIT=-O0 ?

This does not seem to help either way.

(In reply to Tom de Vries from comment #4)
> Can anything be deduced from driver versions?
> Or card architecture?

Maybe. The driver version does not seem to matter – but the card architecture
could:

* Working
  Tesla K40c | NVIDIA-SMI 346.46 Driver Version: 346.46
  Tesla K20c | NVIDIA-SMI 455.38 Driver Version: 455.38 CUDA Version: 11.1
  Tesla K80  | NVIDIA-SMI 440.33.01 Driver Version: 440.33.01 CUDA Version:
10.2

* Failing:
  TITAN V| NVIDIA-SMI 455.23.05 Driver Version: 455.23.05 CUDA Version:
11.1
  Tesla V100-SXM2...| NVIDIA-SMI 410.79 Driver Version: 410.79 CUDA
Version: 10.0
  Quadro GV100  | NVIDIA-SMI 460.32.03  Driver Version: 460.32.03  CUDA
Version: 11.2

[Bug c++/100507] New: ICE on invalid: tree check expects tree that contains 'decl common'

[sand at rifkin dot dev via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100507

Bug ID: 100507
   Summary: ICE on invalid: tree check expects tree that contains
'decl common'
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sand at rifkin dot dev
  Target Milestone: ---

template
void f(auto r){}

Causes an ICE on gcc trunk (11.1 errors correctly):
https://godbolt.org/z/fYe7E9ocM

[Bug bootstrap/100506] bootstrap error: No rule to make target 'gcc/version.c', needed by 'ada/stamp-sdefault'.

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100506

Martin Sebor  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
Martin, does this look familiar to you?

[Bug bootstrap/100506] New: bootstrap error: No rule to make target 'gcc/version.c', needed by 'ada/stamp-sdefault'.

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100506

Bug ID: 100506
   Summary: bootstrap error: No rule to make target
'gcc/version.c', needed by 'ada/stamp-sdefault'.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With today's top of trunk make fails with the error below.  The most recent
change that looks like it might be related is
g:e3a682f4197f9f39808febfd1862e722d7675d34.

My configure options are: --enable-checking=yes,gc --enable-host-shared
--enable-valgrind-annotations
--enable-languages=c,ada,brig,c++,d,fortran,jit,lto,objc,obj-c++

mkdir -p ada/
gcc -c -O0 -g3  -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I.
-Iada/generated -Iada -Iada/gcc-interface -I/ssd/src/gcc/master/gcc/ada
-I/ssd/src/gcc/master/gcc/ada/gcc-interface -Iada/libgnat
-I/ssd/src/gcc/master/gcc/ada/libgnat /ssd/src/gcc/master/gcc/ada/scos.adb -o
ada/scos.o
make[2]: *** No rule to make target '/ssd/src/gcc/master/gcc/version.c', needed
by 'ada/stamp-sdefault'.  Stop.
make[2]: Leaving directory '/ssd/build/gcc-master/gcc'
make[1]: *** [Makefile:4781: all-stage1-gcc] Error 2
make[1]: Leaving directory '/ssd/build/gcc-master'
make: *** [Makefile:27587: stage1-bubble] Error 2
make: Leaving directory '/ssd/build/gcc-master'
Command exited with non-zero status 2

[Bug middle-end/100477] Bogus -Wstringop-overflow warning on memset

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477

Martin Sebor  changed:

   What|Removed |Added

 Blocks||88443

--- Comment #4 from Martin Sebor  ---
The case of _size being very large and n very small may be handled correctly by
the original code thanks to the check for _capacity but because its value isn't
known it affects neither the codegen nor the warning.

The warning is designed to flag bounds greater than PTRDIFF_MAX and that's just
what it sees here as is evident from the output of the -fdump-tree-optimized
option.  There is nothing to fix here.  Code that's unreachable as a result of
preconditions GCC cannot prove may be susceptible to false positives.  That's a
problem shared by all flow-sensitive warnings, not just in GCC but in all
static analyzers with flow analysis.

In general, GCC warnings are designed to "report constructions that are not
inherently erroneous but that are risky or suggest there may have been an
error."  Not every instance of every warning necessarily corresponds to an
error, and some may even be false positives.  Unhelpful warnings can be
disabled either globally, on the command line, or on a case by case basis by
#pragma GCC diagnostic.

Adding preconditions like 'if (_size >= __PTRDIFF_MAX__ / 4)
__builtin_unreachable ();' (the 4 should be replaced by sizeof (value_type) in
the original test case) often helps not just warnings but also codegen. 
They're not required but can be helpful and preferable to suppression.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[vries at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #5 from Tom de Vries  ---
Does it pass with GOMP_NVPTX_JIT=-O0 ?

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[vries at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #4 from Tom de Vries  ---
(In reply to Tobias Burnus from comment #2)

> See below, fails with 4 systems, works with 3 others.

Can anything be deduced from driver versions?

Or card architecture?

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[vries at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #3 from Tom de Vries  ---
Doesn't fail for me unfortunately.

I've tried with GOMP_NVPTX_JIT=-O0..-O4, no luck.

[Bug c++/100485] False positive in -Wmismatched-new-delete

[fiesh at zefix dot tv via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485

--- Comment #7 from fiesh at zefix dot tv ---
Thanks for the outline!  We'll turn off -Wmismatched-new-delete with GCC 11 and
try to switch to the selective opt-out with pragmas in 12.  That's a good
workaround for now.

On a random related note, the man page says -Wmismatched-new-delete is enabled
by default, but playing around with it, it seems it's only turned on by -Wall:
https://godbolt.org/z/n1s6Y8G85

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[tom.vanderaa at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471

--- Comment #5 from Tom Vander Aa  ---

This seems also to fix the original code, which I used to derive the test case.
(patch applied on master)

[Bug c++/100485] False positive in -Wmismatched-new-delete

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485

--- Comment #6 from Martin Sebor  ---
That does sound frustrating, sorry.  The #pragma has a limitation that can make
it difficult to use in inlining contexts.  I submitted a patch for it for GCC
11 but it got pushed to GCC 12 (see pr98465 comment 32).  Until it's fixed, the
only other solution I can think of is to prevent the member operator delete
from inlining using attribute noinline.

[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056017.html

[Bug c/100505] ICE: in record_in_finally_tree, at tree-eh.c:213

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100505

--- Comment #2 from Chengnian Sun  ---
Should I avoid reporting test programs with __GIMPLE or __RTL?

[Bug c/100505] ICE: in record_in_finally_tree, at tree-eh.c:213

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100505

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
__GIMPLE and __RTL expects correct input and handles just limited diagnostics.
I think especially error-recovery for these are WONTFIX.

[Bug tree-optimization/100503] A possible divide by zero problem in function do_rpo_vn

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100503

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-05-10

[Bug c/100505] New: ICE: in record_in_finally_tree, at tree-eh.c:213

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100505

Bug ID: 100505
   Summary: ICE: in record_in_finally_tree, at tree-eh.c:213
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) [master revision
:fb3a8fb4a:25f9f35a85ffee808fc1482b14d91176df59751b] (GCC)

$ cat mutant.c
__GIMPLE
foo() {
bb1:
bb1:
bb1:;
}

$ gcc-trunk  mutant.c
mutant.c:1:1: error: ‘__GIMPLE’ only valid with ‘-fgimple’
1 | __GIMPLE
  | ^~~~
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | foo() {
  | ^~~
mutant.c: In function ‘foo’:
mutant.c:4:1: error: duplicate label ‘bb1’
4 | bb1:
  | ^~~
mutant.c:3:1: note: previous definition of ‘bb1’ with type ‘void’
3 | bb1:
  | ^~~
mutant.c:5:1: error: duplicate label ‘bb1’
5 | bb1:;
  | ^~~
mutant.c:3:1: note: previous definition of ‘bb1’ with type ‘void’
3 | bb1:
  | ^~~
during GIMPLE pass: eh
mutant.c:2:1: internal compiler error: in record_in_finally_tree, at
tree-eh.c:213
2 | foo() {
  | ^~~
0xf5fe56 record_in_finally_tree
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree-eh.c:213
0xf5fe56 record_in_finally_tree
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree-eh.c:203
0xf64d79 collect_finally_tree_1
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree-eh.c:229
0xf64d79 execute
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree-eh.c:2197
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c/100504] New: ICE: tree check: expected string_cst, have integer_cst in get_attr_len, at multiple_target.c:198

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100504

Bug ID: 100504
   Summary: ICE: tree check: expected string_cst, have integer_cst
in get_attr_len, at multiple_target.c:198
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) [master revision
:fb3a8fb4a:25f9f35a85ffee808fc1482b14d91176df59751b] (GCC)

$ cat mutant.c
__attribute__((target_clones(0))) foo() {}

$ gcc-trunk  mutant.c
mutant.c:1:35: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | __attribute__((target_clones(0))) foo() {}
  |   ^~~
during IPA pass: targetclone
mutant.c:1:1: internal compiler error: tree check: expected string_cst, have
integer_cst in get_attr_len, at multiple_target.c:198
1 | __attribute__((target_clones(0))) foo() {}
  | ^
0x7bc9f2 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree.c:8674
0x89f9a4 tree_check(tree_node*, char const*, int, char const*, tree_code)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/tree.h:3356
0x89f9a4 get_attr_len
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/multiple_target.c:198
0x89f9a4 expand_target_clones
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/multiple_target.c:344
0x89f9a4 ipa_target_clone
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/multiple_target.c:517
0x89f9a4 execute
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/multiple_target.c:553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/100503] New: A possible divide by zero problem in function do_rpo_vn

[yguoaz at cse dot ust.hk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100503

Bug ID: 100503
   Summary: A possible divide by zero problem in function
do_rpo_vn
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yguoaz at cse dot ust.hk
  Target Milestone: ---

In gcc/tree-ssa-sccvn.c, the function do_rpo_vn has the following code (link to
the code location:
https://github.com/gcc-mirror/gcc/blob/releases/gcc-11/gcc/tree-ssa-sccvn.c#L7815-#L7842)

static unsigned
do_rpo_vn (function *fn, edge entry, bitmap exit_bbs,
   bool iterate, bool eliminate) {
...
int nex = 0;
...
for (int i = 0; i < n; ++i) {
basic_block bb = BASIC_BLOCK_FOR_FN (fn, rpo[i]);
if (bb->flags & BB_EXECUTABLE)
nex++;
}
...
statistics_histogram_event (cfun, "RPO iterations", 10*nblk / nex);
}

In the loop, the code counts the number of basic blocks with BB_EXECUTABLE flag
in variable nex and use it as divisor after exiting the loop. If no basic block
has such flag, then we will have a divide by zero problem. Is this possible ?
Or we must have at least one bb with the flag BB_EXECUTABLE ?

[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-05-10

--- Comment #3 from Jakub Jelinek  ---
constexpr.c (cxx_eval_call_expression) has:
  if (DECL_CLONED_FUNCTION_P (fun))
fun = DECL_CLONED_FUNCTION (fun);
and similarly constexpr.c (maybe_save_constexpr_fundef) has:
  if (processing_template_decl
  || !DECL_DECLARED_CONSTEXPR_P (fun)
  || cp_function_chain->invalid_constexpr
  || DECL_CLONED_FUNCTION_P (fun))
return;
which means instead of calling during constexpr evaluation the deleting
destructor (_ZN3FooD0Ev) we call the destructor it is cloned from (_ZN3FooD4Ev)
and that means we don't constexpr evaluate the actual delete operator call.
I guess it would be possible to remember
DECL_DELETING_DESTRUCTOR_P (fun) from before the fun = DECL_CLONED_FUNCTION
(fun); and constexpr evaluate a delete operator call, but I'm afraid I have no
idea how this works for constructors or any other cloned function either, how
do we figure out what arguments to bind to e.g. in_chrg argument etc.?

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #2 from Tobias Burnus  ---
(In reply to Tom de Vries from comment #1)
> Can you post a minimal version?

See below, fails with 4 systems, works with 3 others.

#define N 1024

int
main ()
{
  _Complex float orfc = 0;
  // _Complex int orfc = 0;  // variant; uses a GNU extension
  int rf[N] = {};   // Can also be _Complex (float/int) as in the orig example
  rf[5] = 1;

  #pragma omp target teams distribute parallel for reduction(||: orfc)
map(orfc)
  for (int i=0; i < N; ++i)
orfc = orfc || rf[i];

  if (__real__ orfc != 1.0)  // if it fails, it is 0.0 + 0.0i
__builtin_abort ();

  return 0;
}

[Bug c++/100502] New: ICE in enforce_access at cp/semantics.c:368

[raffael at casagrande dot ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100502

Bug ID: 100502
   Summary: ICE in enforce_access at cp/semantics.c:368
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raffael at casagrande dot ch
  Target Milestone: ---

Compile the following source file:

#include 

template 
struct EnumeratorRange {
  struct Iterator {
EnumeratorRange* range_;

friend auto operator==(const Iterator&, const Iterator& i) noexcept -> bool
{
  return i.range_->end_reached_;
}
  };

 private:
  bool end_reached_;
};

with current trunk (V12.0.0 20210509) or with gcc 11.1 on Ubuntu 20.04 using
the command line "g++-11 -std=c++20 main.cc". This produces the following ICE:
Compiler stderr

: In function 'bool operator==(const EnumeratorRange<
 >::Iterator&, const EnumeratorRange<
 >::Iterator&)':
:9:24: internal compiler error: in enforce_access, at
cp/semantics.c:368
9 |   return i.range_->end_reached_;
  |^~~~
0x1d07289 internal_error(char const*, ...)
???:0
0x6bddc3 fancy_abort(char const*, int, char const*)
???:0
0x97a0ba perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int,
access_failure_info*)
???:0
0x971ece lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
???:0
0x9ed934 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
???:0
0x8e4d1d c_parse_file()
???:0
0xa653b2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

See also https://godbolt.org/z/PeGMvKeqd

[Bug tree-optimization/100487] A possible divide by zero bug in jump_table_cluster::emit

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100487

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-05-10

--- Comment #1 from Martin Liška  ---
Mine, thanks for the report.

[Bug target/97792] ICE in extract_insn, at recog.c:2315

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97792

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Liška  ---
Yes, it's really gone.

[Bug ipa/100413] [11/12 Regression] ICE: failed to reclaim unneeded function with custom flags

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100413

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-05-10
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
I can take a look.

[Bug tree-optimization/96915] ICE in tree-switch-conversion

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96915

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Martin Liška  ---
Fixed.

[Bug tree-optimization/42587] bswap not recognized for memory

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #15 from H.J. Lu  ---
Fixed as of GCC 8.2

[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Martin Liška  ---
Mine.

[Bug tree-optimization/42587] bswap not recognized for memory

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587

--- Comment #14 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:1f94ed3b4c308c9da7baf59ecbc0f953e994f9c4

commit r12-664-g1f94ed3b4c308c9da7baf59ecbc0f953e994f9c4
Author: H.J. Lu 
Date:   Sat May 8 07:23:25 2021 -0700

Add a test for PR tree-optimization/42587

PR tree-optimization/42587
* gcc.dg/optimize-bswapsi-6.c: New test.

[Bug c/100501] New: ICE: segmentation fault on embedded asm code

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100501

Bug ID: 100501
   Summary: ICE: segmentation fault on embedded asm code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) [master revision
:fb3a8fb4a:25f9f35a85ffee808fc1482b14d91176df59751b] (GCC)
$
$ gcc-trunk mutant.c
mutant.c: In function ‘foo’:
mutant.c:5:16: internal compiler error: Segmentation fault
4 |   : "m"(({
  | ~~
5 | if (8)
  | ~~~^~~
6 |   ;
  |   ~
7 |   })));
  |   ~~
0xef73e3 crash_signal
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/toplev.c:327
0xbead04 is_gimple_variable
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimple-expr.h:84
0xbead04 is_gimple_id
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimple-expr.h:95
0xbead04 is_gimple_addressable
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimple-expr.h:122
0xbead04 is_gimple_lvalue(tree_node*)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimple-expr.c:595
0xc2742d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:15038
0xc30a7d gimplify_asm_expr
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:6506
0xc26765 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:14416
0xc28fca gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:6877
0xc297fe gimplify_bind_expr
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:1421
0xc25a33 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:14284
0xc28fca gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:6877
0xc2a5c3 gimplify_body(tree_node*, bool)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:15328
0xc2aa11 gimplify_function_tree(tree_node*)
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/gimplify.c:15482
0xa7e737 cgraph_node::analyze()
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cgraphunit.c:670
0xa81641 analyze_functions
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cgraphunit.c:1234
0xa82111 symbol_table::finalize_compilation_unit()
/tmp/tmp.FRQzt2wMfl-gcc-builder/gcc/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
$ cat mutant.c
void foo() {
  __asm__(""
  :
  : "m"(({
if (8)
  ;
  })));
}
$

[Bug c/100500] New: ICE with local label in OpenACC 'loop' region

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100500

Bug ID: 100500
   Summary: ICE with local label in OpenACC 'loop' region
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openacc
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 50786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50786=edit
'c-c++-common/goacc/prN.c'

Discovered in a builld of commit 3bc0d418a5d214a8ba57857656ca5c618df1a4bb
sources, both for C, C++:

[...]/prN.c: In function ‘f._omp_fn.0’:
[...]/prN.c:10:1: error: label ‘l’ in the middle of basic block 9
   10 | }
  | ^
during GIMPLE pass: fixup_cfg
[...]/prN.c:10:1: internal compiler error: verify_flow_info failed

#0  error (gmsgid=gmsgid@entry=0x1f5b4d0 "label %qD in the middle of basic
block %d") at [...]/gcc/diagnostic.c:1697
#1  0x00f0d266 in gimple_verify_flow_info () at
[...]/gcc/tree-cfg.c:5612
#2  0x00925fe4 in verify_flow_info () at [...]/gcc/cfghooks.c:267
#3  0x00d81d13 in execute_function_todo (fn=0x776ad0b8,
data=) at [...]/gcc/passes.c:2054
#4  0x00d825fa in execute_todo (flags=64) at
[...]/gcc/passes.c:2096
#5  0x00d8552f in execute_one_pass (pass=pass@entry=0x2d19f30) at
[...]/gcc/passes.c:2604
#6  0x00d85b68 in execute_pass_list_1 (pass=0x2d19f30) at
[...]/gcc/passes.c:2656
#7  0x00d85bc5 in execute_pass_list (fn=,
pass=) at [...]/gcc/passes.c:2667
#8  0x00d86c31 in do_per_function_toporder (callback=0xd85bb0
, data=0x2d19f30) at
[...]/gcc/passes.c:1773
#9  0x00d86d67 in execute_ipa_pass_list (pass=0x2d19ed0) at
[...]/gcc/passes.c:3003
#10 0x00969bbf in ipa_passes () at [...]/gcc/cgraphunit.c:2154
#11 symbol_table::compile (this=this@entry=0x77543000) at
[...]/gcc/cgraphunit.c:2289
#12 0x0096db5e in symbol_table::compile (this=0x77543000) at
[...]/gcc/cgraphunit.c:2269
#13 symbol_table::finalize_compilation_unit (this=0x77543000) at
[...]/gcc/cgraphunit.c:2537
#14 0x00ec3bce in compile_file () at [...]/gcc/toplev.c:482
#15 0x0075a4ec in do_compile () at [...]/gcc/toplev.c:2201
#16 toplev::main (this=this@entry=0x7fffd4f0, argc=argc@entry=32,
argv=argv@entry=0x7fffd608) at [...]/gcc/toplev.c:2340
#17 0x0075d0f7 in main (argc=32, argv=0x7fffd608) at
[...]/gcc/main.c:39

#0  internal_error (gmsgid=gmsgid@entry=0x1ec3d7b "verify_flow_info
failed") at [...]/gcc/diagnostic.c:1803
#1  0x009260d8 in verify_flow_info () at [...]/gcc/cfghooks.c:269
#2  0x00d81d13 in execute_function_todo (fn=0x776ad0b8,
data=) at [...]/gcc/passes.c:2054
#3  0x00d825fa in execute_todo (flags=64) at
[...]/gcc/passes.c:2096
#4  0x00d8552f in execute_one_pass (pass=pass@entry=0x2d19f30) at
[...]/gcc/passes.c:2604
#5  0x00d85b68 in execute_pass_list_1 (pass=0x2d19f30) at
[...]/gcc/passes.c:2656
#6  0x00d85bc5 in execute_pass_list (fn=,
pass=) at [...]/gcc/passes.c:2667
#7  0x00d86c31 in do_per_function_toporder (callback=0xd85bb0
, data=0x2d19f30) at
[...]/gcc/passes.c:1773
#8  0x00d86d67 in execute_ipa_pass_list (pass=0x2d19ed0) at
[...]/gcc/passes.c:3003
#9  0x00969bbf in ipa_passes () at [...]/gcc/cgraphunit.c:2154
#10 symbol_table::compile (this=this@entry=0x77543000) at
[...]/gcc/cgraphunit.c:2289
#11 0x0096db5e in symbol_table::compile (this=0x77543000) at
[...]/gcc/cgraphunit.c:2269
#12 symbol_table::finalize_compilation_unit (this=0x77543000) at
[...]/gcc/cgraphunit.c:2537
#13 0x00ec3bce in compile_file () at [...]/gcc/toplev.c:482
#14 0x0075a4ec in do_compile () at [...]/gcc/toplev.c:2201
#15 toplev::main (this=this@entry=0x7fffd4f0, argc=argc@entry=32,
argv=argv@entry=0x7fffd608) at [...]/gcc/toplev.c:2340
#16 0x0075d0f7 in main (argc=32, argv=0x7fffd608) at
[...]/gcc/main.c:39

Haven't tried very hard, but couldn't reproduce with OpenMP, so possibly a
problem in the OpenACC 'loop' handling.

[Bug c/91193] ICE on invalid: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91193

Chengnian Sun  changed:

   What|Removed |Added

 CC||cnsun at uwaterloo dot ca

--- Comment #5 from Chengnian Sun  ---
A duplicate

```
typedef xtype;
xtype xtype() xtype a;
{}
```

[Bug fortran/64763] [OpenACC] !$acc region not implemented

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64763

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Keywords|rejects-valid   |

--- Comment #2 from Thomas Schwinge  ---
There's some '!$acc routine' vs. '!$acc region' confusion here.  ;-) The latter
is a non-standard thing (pre-dating standard OpenACC, and certainly not in wide
use, as far as I can tell), and the former has now been available for OpenACC
C/C++/Fortran for quite some time.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471

--- Comment #4 from Jakub Jelinek  ---
Created attachment 50785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50785=edit
gcc12-pr100471.patch

Untested fix.

[Bug d/100324] gcc-10.2.0 (and earlier) fails to build on x86_64, but has builds just fine aarch64

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324

--- Comment #8 from Iain Buclaw  ---
(In reply to Tor from comment #6)
> Built with -j 256 on aarch64 Cavium Tx2 CN9980 nodes. Worked like a charm.
> 
> Not sure why "dash" is ok, while "bash" is not!? Do you?
> 
> I will set default shell to dash on amd64/x86_64 and see how it goes. 
> 
> Thx.
Ran make -j64 using bash on AMD Ryzen Threadripper 3960X 24-Core, don't get any
issues building libphobos.

[Bug tree-optimization/100452] g++.dg/vect/slp-pr99971.cc FAILs

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Richard Biener  ---
Thanks, fixed.

[Bug tree-optimization/100452] g++.dg/vect/slp-pr99971.cc FAILs

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:cce4471bb45f72820eb6c15b4a75e67f704b209e

commit r12-662-gcce4471bb45f72820eb6c15b4a75e67f704b209e
Author: Richard Biener 
Date:   Mon May 10 13:22:03 2021 +0200

testsuite/100452 - fix g++.dg/vect/slp-pr99971.cc

This makes sure to align data so targets without unaligned
accesses can vectorize it.

2021-05-10  Richard Biener  

PR testsuite/100452
* g++.dg/vect/slp-pr99971.cc: Align data.

[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.1.0
 Ever confirmed|0   |1
   Keywords||needs-bisection, wrong-code
 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-05-10
  Known to fail||10.3.1, 8.4.1, 9.3.1

--- Comment #1 from Richard Biener  ---
Confirmed.  It looks like GCC 11 works (it's not vectorizing).  I wonder what
fixed it.

[Bug tree-optimization/100492] [10/11/12 Regression] wrong code at -O3 (generated code hangs)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100492

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:60af2db18013a0339302928ba98fee893ccc1957

commit r12-661-g60af2db18013a0339302928ba98fee893ccc1957
Author: Richard Biener 
Date:   Mon May 10 11:37:27 2021 +0200

tree-optimization/100492 - avoid irreducible regions in loop distribution

When we distribute away a condition we rely on the ability to
change it to either 1 != 0 or 0 != 0 depending on the direction
of the exit branch in the respective loop.  But when the loop
contains an irreducible sub-region then for the conditions inside
this this fails and can lead to infinite loops being generated.

Avoid distibuting loops with irreducible sub-regions.

2021-05-10  Richard Biener  

PR tree-optimization/100492
* tree-loop-distribution.c (find_seed_stmts_for_distribution):
Find nothing when the loop contains an irreducible region.

* gcc.dg/torture/pr100492.c: New testcase.

[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems

[vries at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497

--- Comment #1 from Tom de Vries  ---
Can you post a minimal version?

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2021-05-10

--- Comment #3 from Jakub Jelinek  ---
The bug isn't specific to UDRs, but about the taskloop having zero iterations,
GOMP_taskloop in the library performing an early return as there is no work to
do (but it would do similar thing if containing parallel got cancelled), which
means
  if (flags & GOMP_TASK_FLAG_REDUCTION)
{
  struct gomp_data_head { TYPE t1, t2; uintptr_t *ptr; };
  uintptr_t *ptr = ((struct gomp_data_head *) data)->ptr;
  ialias_call (GOMP_taskgroup_reduction_register) (ptr);
}
wasn't performed.  But in the code emitted in the caller of GOMP_taskloop GCC
relies on that being done.

[Bug tree-optimization/100499] New: Different results with -fpeel-loops -ftree-loop-vectorize options

[dongjianqiang2 at huawei dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499

Bug ID: 100499
   Summary: Different results with -fpeel-loops
-ftree-loop-vectorize options
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dongjianqiang2 at huawei dot com
  Target Milestone: ---

cat demo.c
#include
typedef unsigned short uint16_t;
typedef signed int int32_t;
static uint16_t g_2823 = 0xEC75L;
static uint16_t g_116 = 0xBC07L;

static uint16_t
(safe_mul_func_uint16_t_u_u)(uint16_t ui1, uint16_t ui2 )
{

  return ((unsigned int)ui1) * ((unsigned int)ui2);
}

int main (int argc, char* argv[])
{
uint16_t l_2815 = 65535UL;
uint16_t *l_2821 = _116;
uint16_t *l_2822 = _2823;

printf ("start g_2823 = %d\n", g_2823);
lbl_2826:
l_2815 &= 0x9DEF1EAEL;
if (+(safe_mul_func_uint16_t_u_u(((*l_2821) = l_2815), (--(*l_2822)
{
  goto lbl_2826;
}
printf ("end g_2823 = %d\n", g_2823);

return 0;
}

Compiling with 

gcc demo.c -O1
./a.out
start g_2823 = 60533
end g_2823 = 32768

gcc demo.c -O1 -fpeel-loops -ftree-loop-vectorize
./a.out
start g_2823 = 60533
end g_2823 = 60526

gives different results

[Bug c++/94695] Implement -Wrange-loop-analysis

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94695

Jonathan Wakely  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 80542 has been marked as a duplicate of this bug. ***

[Bug c++/80542] Warn about accidental copying of data in range based for

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80542

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Yes, thanks. Let's close it as a dup of the bug that added the warning (even
though this one is older).

*** This bug has been marked as a duplicate of bug 94695 ***

[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485

Jonathan Wakely  changed:

   What|Removed |Added

 CC||wolfgang.roe...@gi-de.com

--- Comment #11 from Jonathan Wakely  ---
*** Bug 100498 has been marked as a duplicate of this bug. ***

[Bug c++/100498] SFINAE and static inline function

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100498

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
(In reply to Wolfgang Roehrl from comment #0)
> I would like to post a bug report for the GNU C/C++ compiler 7.5.0.

Please don't :-)

The oldest supported release is 8.4.0 and even the 8,x branch is almost out of
support, so please try using a current release before reporting bugs.

This was already fixed by this commit:

PR c++/80485 - inline function non-zero address.

* symtab.c (nonzero_address): Check DECL_COMDAT.

From-SVN: r260762

Your code works correctly in GCC 8.2.0 and later

*** This bug has been marked as a duplicate of bug 80485 ***

[Bug tree-optimization/100464] [11 Regression] emitted binary code changes when -g is enabled at -O3

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464

Richard Biener  changed:

   What|Removed |Added

  Known to fail|11.0|11.1.0
Summary|[11/12 Regression] emitted  |[11 Regression] emitted
   |binary code changes when -g |binary code changes when -g
   |is enabled at -O3   |is enabled at -O3
  Known to work||12.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.  Let's watch the fireworks.

[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44462
Bug 44462 depends on bug 100434, which changed state.

Bug 100434 Summary: DSE fails to DSE aggregate LHS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100434

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/100434] DSE fails to DSE aggregate LHS.

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100434

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/100492] [10/11/12 Regression] wrong code at -O3 (generated code hangs)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100492

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.0|10.4
Summary|[12 Regression] wrong code  |[10/11/12 Regression] wrong
   |at -O3 (generated code  |code at -O3 (generated code
   |hangs)  |hangs)
   Priority|P1  |P2

[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:a076632e274abe344ca7648b7c7f299273d4cbe0

commit r12-657-ga076632e274abe344ca7648b7c7f299273d4cbe0
Author: Richard Biener 
Date:   Fri May 7 09:51:18 2021 +0200

middle-end/100464 - avoid spurious TREE_ADDRESSABLE in folding debug stmts

canonicalize_constructor_val was setting TREE_ADDRESSABLE on bases
of ADDR_EXPRs but that's futile when we're dealing with CTOR values
in debug stmts.  This rips out the code which was added for Java
and should have been an assertion when we didn't have debug stmts.
To not regress g++.dg/tree-ssa/array-temp1.C we have to adjust the
testcase to not look for a no longer applied invalid optimization.

2021-05-10  Richard Biener  

PR middle-end/100464
PR c++/100468
gcc/
* gimple-fold.c (canonicalize_constructor_val): Do not set
TREE_ADDRESSABLE.

gcc/cp/
* call.c (set_up_extended_ref_temp): Mark the temporary
addressable if the TARGET_EXPR was.

gcc/testsuite/
* gcc.dg/pr100464.c: New testcase.
* g++.dg/tree-ssa/array-temp1.C: Adjust.