[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572 --- Comment #4 from Arseny Solokha --- *** Bug 83570 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83570] New: [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83570
Bug ID: 83570
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version: 8.0
Status: RESOLVED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Status: RESOLVED
Resolution: DUPLICATE
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -fno-tree-loop-im:
int u0, l1;
void
u3 (int s1)
{
for (;;)
{
for (u0 = 0; u0 < 2; ++u0)
{
}
if (s1 != 0)
for (l1 = 0; l1 < 2; ++l1)
{
}
l1 = 0;
}
}
% gcc-8.0.0-alpha20171217 -O1 -floop-nest-optimize -fno-tree-loop-im -c
zhhdupzl.c
zhhdupzl.c: In function 'u3':
zhhdupzl.c:4:1: error: dominator of 7 should be 15, not 13
u3 (int s1)
^~
during GIMPLE pass: graphite
zhhdupzl.c:4:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x5dbb02 verify_dominators(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:1184
0x9d5935 checking_verify_dominators
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.h:76
0x9d5935 calculate_dominance_info(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:746
0xda9896 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-into-ssa.c:3332
0x14215c1 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:396
0x14226b0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:447
0x14226b0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:524
--- Comment #1 from Arseny Solokha ---
.
*** This bug has been marked as a duplicate of bug 83572 ***
[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575 --- Comment #2 from Arseny Solokha --- *** Bug 83571 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/83571] New: [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83571
Bug ID: 83571
Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
Product: gcc
Version: 8.0
Status: RESOLVED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Status: RESOLVED
Resolution: DUPLICATE
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -funroll-loops -fno-tree-dominator-opts
-fno-tree-loop-im -fno-code-hoisting -fno-tree-pre
-fno-guess-branch-probability:
int tw, be;
void
fp (void)
{
if (tw == 0)
goto gq;
else if (be == 0)
goto ob;
else
return;
for (;;)
if (tw < 1)
{
while (tw < 1)
{
gq:
tw = 0;
}
while (be < 1)
{
ob:
tw = 0;
}
while (be < 1)
++be;
}
}
% gcc-8.0.0-alpha20171217 -O2 -funroll-loops -fno-tree-dominator-opts
-fno-tree-loop-im -fno-code-hoisting -fno-tree-pre
-fno-guess-branch-probability -c c6kesbr0.c
c6kesbr0.c: In function 'fp':
c6kesbr0.c:31:1: error: multiple hot/cold transitions found (bb 7)
}
^
c6kesbr0.c:31:1: error: multiple hot/cold transitions found (bb 13)
during RTL pass: bbro
c6kesbr0.c:31:1: internal compiler error: verify_flow_info failed
0x968002 verify_flow_info()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfghooks.c:265
0x13a3b11 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/bb-reorder.c:2576
--- Comment #1 from Arseny Solokha ---
.
*** This bug has been marked as a duplicate of bug 83575 ***
[Bug rtl-optimization/83575] New: [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575
Bug ID: 83575
Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -funroll-loops -fno-tree-dominator-opts
-fno-tree-loop-im -fno-code-hoisting -fno-tree-pre
-fno-guess-branch-probability:
int tw, be;
void
fp (void)
{
if (tw == 0)
goto gq;
else if (be == 0)
goto ob;
else
return;
for (;;)
if (tw < 1)
{
while (tw < 1)
{
gq:
tw = 0;
}
while (be < 1)
{
ob:
tw = 0;
}
while (be < 1)
++be;
}
}
% gcc-8.0.0-alpha20171217 -O2 -funroll-loops -fno-tree-dominator-opts
-fno-tree-loop-im -fno-code-hoisting -fno-tree-pre
-fno-guess-branch-probability -c c6kesbr0.c
c6kesbr0.c: In function 'fp':
c6kesbr0.c:31:1: error: multiple hot/cold transitions found (bb 7)
}
^
c6kesbr0.c:31:1: error: multiple hot/cold transitions found (bb 13)
during RTL pass: bbro
c6kesbr0.c:31:1: internal compiler error: verify_flow_info failed
0x968002 verify_flow_info()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfghooks.c:265
0x13a3b11 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/bb-reorder.c:2576
--- Comment #1 from Arseny Solokha ---
*** Bug 83578 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572 --- Comment #3 from Arseny Solokha --- *** Bug 83576 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572 --- Comment #2 from Arseny Solokha --- *** Bug 83577 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83576] New: [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83576
Bug ID: 83576
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version: 8.0
Status: RESOLVED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Status: RESOLVED
Resolution: DUPLICATE
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -fno-tree-loop-im:
int u0, l1;
void
u3 (int s1)
{
for (;;)
{
for (u0 = 0; u0 < 2; ++u0)
{
}
if (s1 != 0)
for (l1 = 0; l1 < 2; ++l1)
{
}
l1 = 0;
}
}
% gcc-8.0.0-alpha20171217 -O1 -floop-nest-optimize -fno-tree-loop-im -c
zhhdupzl.c
zhhdupzl.c: In function 'u3':
zhhdupzl.c:4:1: error: dominator of 7 should be 15, not 13
u3 (int s1)
^~
during GIMPLE pass: graphite
zhhdupzl.c:4:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x5dbb02 verify_dominators(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:1184
0x9d5935 checking_verify_dominators
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.h:76
0x9d5935 calculate_dominance_info(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:746
0xda9896 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-into-ssa.c:3332
0x14215c1 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:396
0x14226b0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:447
0x14226b0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:524
--- Comment #1 from Arseny Solokha ---
Apparent Bugzilla glitch.
*** This bug has been marked as a duplicate of bug 83572 ***
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #12 from Jason Duerstock --- Some additional information: 1) The code works properly under 6.4.0. 2) The code works properly with -O1 -fno-tree-ter.
[Bug tree-optimization/83574] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83574 Arseny Solokha changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Arseny Solokha --- Apparent Bugzilla glitch. *** This bug has been marked as a duplicate of bug 83572 ***
[Bug rtl-optimization/83578] New: [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83578
Bug ID: 83578
Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -funroll-loops -fno-tree-dominator-opts
-fno-tree-loop-im -fno-code-hoisting -fno-tree-pre
-fno-guess-branch-probability:
int tw, be;
void
fp (void)
{
if (tw == 0)
goto gq;
else if (be == 0)
goto ob;
else
return;
for (;;)
if (tw < 1)
{
while (tw < 1)
{
gq:
tw = 0;
}
while (be < 1)
{
ob:
tw = 0;
}
while (be < 1)
++be;
}
}
% gcc-8.0.0-alpha20171217 -O2 -funroll-loops -fno-tree-dominator-opts
-fno-tree-loop-im -fno-code-hoisting -fno-tree-pre
-fno-guess-branch-probability -c c6kesbr0.c
c6kesbr0.c: In function 'fp':
c6kesbr0.c:31:1: error: multiple hot/cold transitions found (bb 7)
}
^
c6kesbr0.c:31:1: error: multiple hot/cold transitions found (bb 13)
during RTL pass: bbro
c6kesbr0.c:31:1: internal compiler error: verify_flow_info failed
0x968002 verify_flow_info()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfghooks.c:265
0x13a3b11 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/bb-reorder.c:2576
[Bug tree-optimization/83577] New: [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83577
Bug ID: 83577
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -fno-tree-loop-im:
int u0, l1;
void
u3 (int s1)
{
for (;;)
{
for (u0 = 0; u0 < 2; ++u0)
{
}
if (s1 != 0)
for (l1 = 0; l1 < 2; ++l1)
{
}
l1 = 0;
}
}
% gcc-8.0.0-alpha20171217 -O1 -floop-nest-optimize -fno-tree-loop-im -c
zhhdupzl.c
zhhdupzl.c: In function 'u3':
zhhdupzl.c:4:1: error: dominator of 7 should be 15, not 13
u3 (int s1)
^~
during GIMPLE pass: graphite
zhhdupzl.c:4:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x5dbb02 verify_dominators(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:1184
0x9d5935 checking_verify_dominators
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.h:76
0x9d5935 calculate_dominance_info(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:746
0xda9896 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-into-ssa.c:3332
0x14215c1 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:396
0x14226b0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:447
0x14226b0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:524
[Bug tree-optimization/83574] New: [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83574
Bug ID: 83574
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -fno-tree-loop-im:
int u0, l1;
void
u3 (int s1)
{
for (;;)
{
for (u0 = 0; u0 < 2; ++u0)
{
}
if (s1 != 0)
for (l1 = 0; l1 < 2; ++l1)
{
}
l1 = 0;
}
}
% gcc-8.0.0-alpha20171217 -O1 -floop-nest-optimize -fno-tree-loop-im -c
zhhdupzl.c
zhhdupzl.c: In function 'u3':
zhhdupzl.c:4:1: error: dominator of 7 should be 15, not 13
u3 (int s1)
^~
during GIMPLE pass: graphite
zhhdupzl.c:4:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x5dbb02 verify_dominators(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:1184
0x9d5935 checking_verify_dominators
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.h:76
0x9d5935 calculate_dominance_info(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:746
0xda9896 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-into-ssa.c:3332
0x14215c1 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:396
0x14226b0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:447
0x14226b0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:524
[Bug tree-optimization/83572] New: [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572
Bug ID: 83572
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 7 should be 15,
not 13)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -fno-tree-loop-im:
int u0, l1;
void
u3 (int s1)
{
for (;;)
{
for (u0 = 0; u0 < 2; ++u0)
{
}
if (s1 != 0)
for (l1 = 0; l1 < 2; ++l1)
{
}
l1 = 0;
}
}
% gcc-8.0.0-alpha20171217 -O1 -floop-nest-optimize -fno-tree-loop-im -c
zhhdupzl.c
zhhdupzl.c: In function 'u3':
zhhdupzl.c:4:1: error: dominator of 7 should be 15, not 13
u3 (int s1)
^~
during GIMPLE pass: graphite
zhhdupzl.c:4:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x5dbb02 verify_dominators(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:1184
0x9d5935 checking_verify_dominators
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.h:76
0x9d5935 calculate_dominance_info(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/dominance.c:746
0xda9896 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-into-ssa.c:3332
0x14215c1 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:396
0x14226b0 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:447
0x14226b0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/graphite.c:524
[Bug tree-optimization/83573] New: Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83573
Bug ID: 83573
Summary: Wrong constant folding
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
Target Milestone: ---
GCC 8.0 for x86_64 miscompiles the following code.
% cat test.c
int a[2] = {0,1};
int x = 129;
int main (void)
{
volatile int v = 0;
int t = x;
for (int i = 0; i < (1+v+v+v+v+v+v+v+v+a[a[0]]); i++) {
t = a[(signed char)(130-x)];
}
if (t != 1) __builtin_abort();
return 0;
}
% gcc-8.0.0 test.c
% ./a.out
% gcc-8.0.0 test.c -O3
% ./a.out
zsh: abort (core dumped) ./a.out
% gcc-8.0.0 -v
Using built-in specs.
COLLECT_GCC=gcc-8.0.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-8.0.0/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-8.0.0 --disable-nls
--disable-multilib --program-suffix=-8.0.0 --enable-languages=c
Thread model: posix
gcc version 8.0.0 20171215 (experimental) (GCC)
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #11 from Jim Wilson --- On itanium, when you take a paradoxical subreg, the upper bits are undefined. Note for instance that we use the exact same instruction for addsi3 and adddi3. So after an addsi3, the upper bits may be garbage because the add instruction writes to all 64 bits. It is the compare instruction that matters. We have separate cmp4 for SImode and cmp for DImode, where cmp4 ignores the upper bits of the register because they are garbage bits. This part >r358 is known to have the high half zero: > 22: r358:DI=r357:SI#0^r341:SI#0 is wrong. The upper bits of both registers are unknown bits, and xor of unknown bits does not return zero. I think the problem is in nonzero_bits1 in rtlanal.c, in the SUBREG case. On ia64, we have WORD_REGISTER_OPERATIONS true, and load_extend_op of SImode is ZERO_EXTEND, so the code decides that the upper bits must be zero. But LOAD_EXTEND_OP only applies to memory operations, and we do not have a subreg of memory here, we have a subreg of a register. When we have a subreg of a reg, on itanium, the upper bits are unknown. So the optimization performed here is wrong. Though one could perhaps argue that the ia64 port is using WORD_REGISTER_OPERATIONS wrong I suppose. I'm not sure what would happen if we removed that define. Anyways, since addsi3 and many other simode patterns leave the upper bits as garbage, it doesn't make sense to argue that rotate patterns must zero the upper bits.
[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I simply never implemented it for listdirected output. Just an oversight. Working it now.
[Bug c++/83568] thread_local class members not initialized before accessed using operator ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83568
--- Comment #1 from Kan Wang ---
Sorry for wrong paste, the code should be
#include
bool initialized = false;
int init() {
initialized = true;
return 1;
}
struct A {
static thread_local int foo;
};
thread_local int A::foo { init() };
int main() {
A a;
std::cout << a.foo << std::endl;
std::cout << (initialized ? "ok" : "bug" ) << std::endl;
std::cout << A::foo << std::endl;
return 0;
}
Output:
0
bug
1
[Bug c++/83568] New: thread_local class members not initialized before accessed using operator ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83568
Bug ID: 83568
Summary: thread_local class members not initialized before
accessed using operator ::
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tinrow at gmail dot com
Target Milestone: ---
thread_local class members are not initialized as expected, if it is accessed
using member access operator (dot) instead of scope resolution operator :: .
The initialization only happens on the first time it is accessed using operator
:: .
reproducible code (gcc 4.8 - 7.1):
#include
bool initialized = false;
int init() {
initialized = true;
return 1;
}
struct A {
static thread_local int foo;
};
thread_local int A::foo { init() };
int main() {
A a;
std::cout << (initialized ? "ok" : "bug" ) << std::endl;
std::cout << a.foo << std::endl;
std::cout << A::foo << std::endl;
return 0;
}
Output:
bug
0
1
[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to cgw from comment #7) > Thanks for the suggestion. I will give it a try. > > However, we're using a gcc from the distribution - either Ubuntu or > Anaconda, depending on the platform. We are not configuring and building > our own gcc. > > Configuring our own gcc is possible, but a lot of extra overhead. However, > we'd like our end-users to be able to modify the code and recompile it. > Asking end-users to configure and build gcc in order to compile our package > is not really an option for us. I recently set up an LUbuntu system and yesterady noticed a link error suggesting that one compile with -fPIC. Now I wonder if the problem I am seeing is the same issue. I did compile the application with -fPIC, but it must be the libgfortran that is the problem.
[Bug fortran/83567] New: Parametrized derived types: Segmentation fault when assigning a function return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567 Bug ID: 83567 Summary: Parametrized derived types: Segmentation fault when assigning a function return value Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: berke.durak at gmail dot com Target Milestone: --- Just wrote a small program to test the new parametrized derived types. Unfortunately I get runtime memory corruption errors and segmentation faults. % cat pdf.f90 module pdt_m implicit none type :: vec(k) integer, len :: k=3 integer :: foo(k)=[1,2,3] end type vec contains function addvv(a,b) result(c) type(vec(k=*)), intent(in) :: a type(vec(k=*)), intent(in) :: b type(vec(k=a%k)) :: c c%foo=a%foo+b%foo end function end module pdt_m program test_pdt use pdt_m implicit none type(vec) :: u,v,w u%foo=[1,2,3] v%foo=[2,3,4] w=addvv(u,v) print *,w end program test_pdt % gfortran-8 --version GNU Fortran (Debian 8-20171223-1) 8.0.0 20171223 (experimental) [trunk revision 255988] % gfortran-8 pdt.f90 -o pdt -Wall -O3 -g -fcheck=all -Wextra % ./pdt 3 0 0 7 *** Error in `./pdt': double free or corruption (fasttop): 0x55cc59c66630 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f303fe40bfb] /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f303fe46fc6] /lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7f303fe4780e] ./pdt(+0xdf0)[0x55cc59a0fdf0] ./pdt(+0x89f)[0x55cc59a0f89f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f303fdf02e1] ./pdt(+0x8da)[0x55cc59a0f8da] === Memory map: 55cc59a0f000-55cc59a11000 r-xp fe:04 1316416 /home/alpha/src/fortran/23_Parametrized_derived_types/pdt 55cc59c1-55cc59c11000 r--p 1000 fe:04 1316416 /home/alpha/src/fortran/23_Parametrized_derived_types/pdt 55cc59c11000-55cc59c12000 rw-p 2000 fe:04 1316416 /home/alpha/src/fortran/23_Parametrized_derived_types/pdt 55cc59c63000-55cc59c84000 rw-p 00:00 0 [heap] 7f303800-7f3038021000 rw-p 00:00 0 7f3038021000-7f303c00 ---p 00:00 0 7f303fbb6000-7f303fbcf000 r-xp fe:04 393306 /lib/x86_64-linux-gnu/libz.so.1.2.8 7f303fbcf000-7f303fdce000 ---p 00019000 fe:04 393306 /lib/x86_64-linux-gnu/libz.so.1.2.8 7f303fdce000-7f303fdcf000 r--p 00018000 fe:04 393306 /lib/x86_64-linux-gnu/libz.so.1.2.8 7f303fdcf000-7f303fdd rw-p 00019000 fe:04 393306 /lib/x86_64-linux-gnu/libz.so.1.2.8 7f303fdd-7f303ff63000 r-xp fe:04 396680 /lib/x86_64-linux-gnu/libc-2.24.so 7f303ff63000-7f3040163000 ---p 00193000 fe:04 396680 /lib/x86_64-linux-gnu/libc-2.24.so 7f3040163000-7f3040167000 r--p 00193000 fe:04 396680 /lib/x86_64-linux-gnu/libc-2.24.so 7f3040167000-7f3040169000 rw-p 00197000 fe:04 396680 /lib/x86_64-linux-gnu/libc-2.24.so 7f3040169000-7f304016d000 rw-p 00:00 0 7f304016d000-7f30401ab000 r-xp fe:04 5512042 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7f30401ab000-7f30403ab000 ---p 0003e000 fe:04 5512042 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7f30403ab000-7f30403ac000 r--p 0003e000 fe:04 5512042 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7f30403ac000-7f30403ad000 rw-p 0003f000 fe:04 5512042 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7f30403ad000-7f30403c4000 r-xp fe:04 393267 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f30403c4000-7f30405c3000 ---p 00017000 fe:04 393267 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f30405c3000-7f30405c4000 r--p 00016000 fe:04 393267 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f30405c4000-7f30405c5000 rw-p 00017000 fe:04 393267 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f30405c5000-7f30406c8000 r-xp fe:04 396688 /lib/x86_64-linux-gnu/libm-2.24.so 7f30406c8000-7f30408c7000 ---p 00103000 fe:04 396688 /lib/x86_64-linux-gnu/libm-2.24.so 7f30408c7000-7f30408c8000 r--p 00102000 fe:04 396688 /lib/x86_64-linux-gnu/libm-2.24.so 7f30408c8000-7f30408c9000 rw-p 00103000 fe:04 396688 /lib/x86_64-linux-gnu/libm-2.24.so 7f30408c9000-7f3040b1a000 r-xp fe:04 5621520 /usr/lib/x86_64-linux-gnu/libgfortran.so.5.0.0 7f3040b1a000-7f3040d19000 ---p 00251000 fe:04 5621520 /usr/lib/x86_64-linux-gnu/libgfortran.so.5.0.0 7f3040d19000-7f3040d1a000 r--p 0025 fe:04 5621520 /usr/lib/x86_64-linux-gnu
[Bug libstdc++/83566] cyl_bessel_j returns wrong result for x>1000 for high orders.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83566 --- Comment #1 from Ruslan --- > As n decreases, the imprecision gradually gets smaller. To avoid confusion: this statement is for fixed x>1000.
[Bug libstdc++/83566] New: cyl_bessel_j returns wrong result for x>1000 for high orders.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83566
Bug ID: 83566
Summary: cyl_bessel_j returns wrong result for x>1000 for high
orders.
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: b7.10110111 at gmail dot com
Target Milestone: ---
The following test program prints results of C++17
std::cyl_bessel_j(100,1000.0001) and corresponding result given by GSL:
#include
#include
#include
int main()
{
const double volatile n = 100;
const double volatile x = 1000.0001;
std::cout.precision(std::numeric_limits::digits10);
const auto valueCXX17 = std::cyl_bessel_j(n,x);
const auto valueGSL = gsl_sf_bessel_Jn (n,x);
std::cout << "C++17: " << valueCXX17 << "\n"
<< "GSL : " << valueGSL << "\n";
}
I get the following output:
C++17: 0.433818396252946
GSL : 0.0116783669817645
Comparison with Boost.Math and Wolfram Mathematica shows that GSL is right,
while stdc++ is wrong.
For x<=1000 there's no such problem. As n decreases, the imprecision gradually
gets smaller.
[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #4 from urbanjost at comcast dot net --- Yes - just to confirm, I only found a problem with the missing plus with INTEGER values printed without an explicit format. Everything I tried with floating-point values (REAL and COMPLEX) conforms to what I expect per the Fortran standard. INTEGER even works when a format is used, and SP and SS work as expected in a FORMAT even for INTEGERS. The plus prefix is only missing from list-directed output and NAMELIST output for INTEGER values AFAIN. This demonstrates all the wrong ones I found: namelist /nlist/ i open(6,sign='PLUS') i=10 write(*,*)i write(*,nlist) end 10 I= 10, /
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #17 from Petr Špaček --- I found this bug while searching for a way to solve exactly this problem, so for the record: It sounds like very good and useful addition. Thank you!
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #10 from Sergei Trofimovich --- > The patch works on an attached example. Building 7.2.0 with your patch to > check on openssl testsuite. Full openssl-1.0.2n test suite now passes with this patch.
[Bug target/83315] PowerPC xmmintrin.h emulation for _mm_{min,max}_ps not semantically equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83315 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug c++/81837] Internal compiler error (cp/typeck2.c:1264)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81837 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini --- My patch for PR82593 essentially fixed this one too, but I think we can avoid some redundant diagnostics.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #9 from Segher Boessenkool --- #0 means subreg 0; in this case, (subreg:DI (reg:SI 357) 0) etc. (The "slim" RTL dumps are lossy in places btw; in _this_ case you can deduce it has to be DImode, but not always. OTOH slim dumps take up less space ;-) )
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #8 from Sergei Trofimovich --- Ah, tricky. That makes sense! Shows again how bad I am at reading RTL logs. Is there a doc I could get through to understand what '#0' means (my guess it's "zero-extend") in '22: r358:DI=r357:SI#0^r341:SI#0' and such? Thank you!
[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540 --- Comment #4 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #3) > The code uses ALLOCATE without any realloc-lhs!-( The problem shows up for any use of MATMUL as argument to a procedure, whether user-defined or intrinsic. Maybe the problem is just related to the needed temporary. The problem also shows up with optimization for "-std=f95". F95 did not have realloc-lhs, and the code is F95-compatible.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #7 from Segher Boessenkool --- (In reply to Sergei Trofimovich from comment #5) > gcc's try_combine() scares me lots :) It's an acquired taste. > Segher, can you guide me here what changes size of zero_extract in here from > 0x1f to 0x20? Trying 23 -> 24: 23: r359:DI=zero_extract(r358:DI,0x1f,0x1) REG_DEAD r358:DI 24: r356:SI#0=r359:DI REG_DEAD r359:DI Successfully matched this instruction: (set (subreg:DI (reg:SI 356 [ off ]) 0) (lshiftrt:DI (reg:DI 358) (const_int 1 [0x1]))) allowing combination of insns 23 and 24 original costs 4 + 4 = 8 replacement cost 4 deferring deletion of insn with uid = 23. modifying insn i324: r356:SI#0=r358:DI 0>>0x1 REG_DEAD r358:DI deferring rescan insn with uid = 24. [ ... ] Trying 24 -> 29: 24: r356:SI#0=r358:DI 0>>0x1 REG_DEAD r358:DI 29: r8:SI=r356:SI REG_DEAD r356:SI Successfully matched this instruction: (set (reg:DI 8 r8) (zero_extract:DI (reg:DI 358) (const_int 32 [0x20]) (const_int 1 [0x1]))) allowing combination of insns 24 and 29 original costs 4 + 4 = 8 replacement cost 4 deferring deletion of insn with uid = 24. modifying insn i329: r8:DI=zero_extract(r358:DI,0x20,0x1) REG_DEAD r358:DI deferring rescan insn with uid = 29. r358 is known to have the high half zero: 22: r358:DI=r357:SI#0^r341:SI#0 so this is correct. The zero_extract(31,1) is transformed to a shift right, and that then later is transformed to a zero_extract(32,1); there is no transform from 31 to 32 :-) James' patch looks fine fwiw; it's a backend problem.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #6 from Sergei Trofimovich --- (In reply to James Clarke from comment #4) > Created attachment 42961 [details] > Zero-out high 32 bits after a rotate > > Please try the attached patch. The patch works on an attached example. Building 7.2.0 with your patch to check on openssl testsuite. Thank you!
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 Sergei Trofimovich changed: What|Removed |Added CC||segher at kernel dot crashing.org --- Comment #5 from Sergei Trofimovich --- gcc's try_combine() scares me lots :) Segher, can you guide me here what changes size of zero_extract in here from 0x1f to 0x20?
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #4 from James Clarke --- Created attachment 42961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42961=edit Zero-out high 32 bits after a rotate Please try the attached patch.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #3 from James Clarke --- Created attachment 42960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42960=edit rotate test case Jason (in Cc) sent me this example, which is similar. What's basically happening, as far as I understand, is that, since the source for the "extr.u" is being used for a 32-bit integer, it knows that the high 32 bits of the register should be 0, and thus it can always increase the length parameter to 32, but the earlier rotate (which is implemented with a mix4.r, i.e. copy lower 32 bits to upper 32 bits, and a shr.u) doesn't clear out the high 32 bits.
[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399 Segher Boessenkool changed: What|Removed |Added Keywords||ice-on-invalid-code Target|powerpc64le |powerpc64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-23 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Confirmed. It is invalid code, but shouldn't ICE (as it does with -mabi-elfv2, also on BE).
[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #11 from Segher Boessenkool ---
In the 64-bit Power ABIs, an int is passed as a sign-extended 64-bit register.
Take this trivial example:
int f(int x) { return x*x; }
which compiles to (on powerpc64-linux, BE):
.L.f:
mullw 3,3,3 # 6[c=8 l=4] mulsi3/0
extsw 3,3# 12 [c=4 l=4] extendsidi2/1
blr # 19 [c=4 l=4] simple_return
Right before combine it is
2: r122:DI=%3:DI
6: r123:SI=r122:DI#4*r122:DI#4
7: r124:DI=sign_extend(r123:SI)
12: %3:DI=r124:DI
13: use %3:DI
(note %3, the argument, is DI; and r122, the pseudo the argument is copied to,
is DI as well).
So r122 could be made SImode here, instead, because it only ever is used as SI.
But it doesn't hurt here. And knowing it has the proper value in DImode
already
helps optimisation, too (as in long f(int x) { return (long)x + 42; } ).
What is different in your example it there is a *second* assignment to r160
there, where that second assignment has a sign extension, that then isn't
optimised away.
[Bug fortran/83551] ICE on valid code - function with a pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83551
Paul Thomas changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #3)
> Likely fixed by revision r251949 (pr34640 and friends). Considering the size
> of the commit I doubt that it will be back-ported.
It was indeed this patch, whose entire purpose was to catch the reporter's
testcase.
Were the size of the patch the only problem, I would consider backporting to
7-branch. However, the patch breaks the array descriptor ABI and so my
inclination is to mark the PR as RESOLVED.
Gilbert, I have been around the houses on how to fix the likes of your testcase
in other ways. It is indeed valid fortran. It is the last remaining F95
non-compliance of gfortran.
Unfortunately, the original design of the gfortran array descriptor did not
allow for such pointers. For some reason, hidden in the mists of time, the
'dim' triplet chosen was {lbound, stride, ubound}, whereas most (all?) other
compilers use {lbound, stride_measure, extent}. The difference is that stride
is in units of the element length, whereas stride_measure is in bytes so that
elements of derived types can be addressed.
If you can upgrade to 8.0.0, you will be rewarded by having your code work, as
Steve has reported.
Sorry about this - it is a very useful f95 feature.
Paul
[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 --- Comment #7 from cgw at alum dot mit.edu --- Thanks for the suggestion. I will give it a try. However, we're using a gcc from the distribution - either Ubuntu or Anaconda, depending on the platform. We are not configuring and building our own gcc. Configuring our own gcc is possible, but a lot of extra overhead. However, we'd like our end-users to be able to modify the code and recompile it. Asking end-users to configure and build gcc in order to compile our package is not really an option for us.
[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540 --- Comment #3 from Dominique d'Humieres --- > Two possible methods: Either try to use ALLOCATE instead of > assignment for front-end optimization, or simply disallow > matmul for those cases. The code uses ALLOCATE without any realloc-lhs!-(
[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|2008-01-29 14:09:25 |2017-12-23 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- What happens if you follow Andrew's advice in comment 2: > Configure gcc with --with-pic. ?
[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540 --- Comment #2 from Thomas Koenig --- Two possible methods: Either try to use ALLOCATE instead of assignment for front-end optimization, or simply disallow matmul for those cases. I am tempted to do the latter.
[Bug fortran/83551] ICE on valid code - function with a pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83551 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-12-23 CC||pault at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Likely fixed by revision r251949 (pr34640 and friends). Considering the size of the commit I doubt that it will be back-ported.
[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-23 CC||tkoenig at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Likely revision r247755.
[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-23 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Open with SIGN=... has been introduced in revision r133943. AFAICT it worked with REAL, but not with INTEGER.
[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 Aso Renji changed: What|Removed |Added CC||asorenji at gmail dot com --- Comment #13 from Aso Renji --- Still have same problem in g++ 6.3.0. So, please reopen this bug.
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
--- Comment #2 from Sergei Trofimovich ---
Where the change happens (today's gcc master):
$./bin/ia64-unknown-linux-gnu-gcc -O1 -S a.c -fdump-rtl-all
$ fgrep -A3 zero_extract a.c.*
zero_extract extracted 31 bits at offset 1:
a.c.262r.init-regs:(zero_extract:DI (reg:DI 358)
a.c.262r.init-regs-(const_int 31 [0x1f])
a.c.262r.init-regs-(const_int 1 [0x1]))) "a.c":28 159 {extzv}
a.c.262r.init-regs- (expr_list:REG_DEAD (reg:DI 358)
a.c.264r.combine:insn_cost 4 for23: r359:DI=zero_extract(r358:DI,0x1f,0x1)
a.c.264r.combine- REG_DEAD r358:DI
a.c.264r.combine-insn_cost 4 for24: r356:SI#0=r359:DI
a.c.264r.combine- REG_DEAD r359:DI
a.c.264r.combine:modifying insn i329: r8:DI=zero_extract(r358:DI,0x20,0x1)
a.c.264r.combine- REG_DEAD r358:DI
a.c.264r.combine-deferring rescan insn with uid = 29.
a.c.264r.combine-starting the processing of deferred insns
zero_extract extracts 32 bits at offset 1:
a.c.264r.combine:(zero_extract:DI (reg:DI 358)
a.c.264r.combine-(const_int 32 [0x20])
a.c.264r.combine-(const_int 1 [0x1]))) "a.c":33 159 {extzv}
a.c.264r.combine- (expr_list:REG_DEAD (reg:DI 358)
[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #1 from Sergei Trofimovich --- Here is disassembled dump of gcc -O1 result (it's slightly easier to reason about than gcc's assembly output): Dump of assembler code for function bug: 0x45f0 <+0>: [MII] mov r14=r12 // store 'ss=0x' on stack 0x45f1 <+1>: mov r15=-1;; 0x45f2 <+2>: nop.i 0x0 // store 'd=0x' on stack 0x4600 <+16>:[MLX] st4.rel [r14]=r15,4 0x4601 <+17>:movl r15=0x;; // reload 'd' 0x4610 <+32>:[MMI] st4.rel [r14]=r15 0x4611 <+33>:ld4.acq r15=[r14] 0x4612 <+34>:nop.i 0x0 // u32 tt = d & 0x0080; 0x4620 <+48>:[MLX] nop.m 0x0 0x4621 <+49>:movl r14=0x80;; 0x4630 <+64>:[MMI] and r15=r14,r15;; // u32 r = tt << 8; 0x4631 <+65>:nop.m 0x0 0x4632 <+66>:dep.z r14=r15,8,24 0x4640 <+80>:[MMI] ld4.acq r8=[r12] // *result = tt; 0x4641 <+81>:st4 [r32]=r15 0x4642 <+82>:nop.i 0x0;; // rotate //r = (r >> 31) // | (r << 1); 0x4650 <+96>:[MII] nop.m 0x0 0x4651 <+97>:mix4.r r14=r14,r14;; 0x4652 <+98>:shr.u r14=r14,31;; // u32 u = r^ss; 0x4660 <+112>: [MMI] xor r8=r8,r14;; 0x4661 <+113>: nop.m 0x0 // u32 off = u >> 1; // Note how we use 32 bits after 1-bit shift. 0x4662 <+114>: extr.u r8=r8,1,32 0x4670 <+128>: [MIB] nop.m 0x0 0x4671 <+129>: nop.i 0x0 0x4672 <+130>: br.ret.sptk.many b0;; Here 'extr.u r8=r8,1,32' should be 'extr.u r8=r8,1,31' to yield correct result. But something in RTK combine pass decided to expand 31 to 32.
[Bug rtl-optimization/83565] New: RTL combine pass breaks shift result (at least on ia64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565
Bug ID: 83565
Summary: RTL combine pass breaks shift result (at least on
ia64)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 42959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42959=edit
a.c
Original but was seen as an openssl DES testsuite failure.
Below is a distilled example that yields differetn results
when built as -O0 vs. -O1 built:
#include
/*
$ gcc -O0 a.c -o a-O0 && ./a-O0 > o0
$ gcc -O1 a.c -o a-O1 && ./a-O1 > o1
$ diff -U0 o0 o1
-off>>: 7fff
+off>>:
*/
typedef unsigned int u32;
u32 bug (u32 * result) __attribute__((noinline));
u32 bug (u32 * result)
{
// non-static and non-volatile to inhibit constant propagation
volatile u32 ss = 0x;
volatile u32 d = 0x;
u32 tt = d & 0x0080;
u32 r = tt << 8;
// rotate
r = (r >> 31)
| (r << 1);
u32 u = r^ss;
u32 off = u >> 1;
// seemingly unrelated but bug-triggering side-effect
*result = tt;
return off;
}
int main() {
u32 l;
u32 off = bug();
printf ("off>>: %08x\n", off);
return 0;
}
[Bug c++/83564] Compiling 'retdec' causes 'internal compiler error'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564 --- Comment #3 from Markus Trippelsdorf --- (In reply to hjek from comment #2) > (Perhaps the error message should be changed to say that?) Yes. It was fixed for gcc-8.
[Bug c++/83564] Compiling 'retdec' causes 'internal compiler error'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564 --- Comment #2 from hjek at mail dot com --- Makes sense. Thanks. (Perhaps the error message should be changed to say that?)
[Bug c++/83564] Compiling 'retdec' causes 'internal compiler error'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- internal compiler error: Killed (program cc1plus) means you were running out of memory and the OOM killer kicked in. Not a gcc bug.
[Bug c++/83564] New: Compiling 'retdec' causes 'internal compiler error'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83564 Bug ID: 83564 Summary: Compiling 'retdec' causes 'internal compiler error' Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hjek at member dot fsf.org Target Milestone: --- Host: Linux debian 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3 (2017-12-03) i686 GNU/Linux Target: Linux debian 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3 (2017-12-03) i686 GNU/Linux I'm just posting this error because the error message asked me to do it. I was compiling `retdec` from here https://github.com/avast-tl/retdec Output from running `make` in `build` of `retdec`: ``` [...] [ 20%] Building CXX object deps/ctypes/src/ctypes/CMakeFiles/ctypes.dir/void_type.cpp.o [ 20%] Linking CXX static library libctypes.a [ 20%] Built target ctypes Scanning dependencies of target ctypesparser [ 20%] Building CXX object deps/ctypes/src/ctypesparser/CMakeFiles/ctypesparser.dir/ctypes_parser.cpp .o [ 20%] Building CXX object deps/ctypes/src/ctypesparser/CMakeFiles/ctypesparser.dir/json_ctypes_parse r.cpp.o [ 20%] Linking CXX static library libctypesparser.a [ 20%] Built target ctypesparser Scanning dependencies of target demangler [ 20%] Building CXX object deps/demangler/src/demangler/CMakeFiles/demangler.dir/demangler.cpp.o [ 20%] Building CXX object deps/demangler/src/demangler/CMakeFiles/demangler.dir/demtools.cpp.o [ 20%] Building CXX object deps/demangler/src/demangler/CMakeFiles/demangler.dir/gparser.cpp.o [ 20%] Building CXX object deps/demangler/src/demangler/CMakeFiles/demangler.dir/igrams.cpp.o [ 20%] Building CXX object deps/demangler/src/demangler/CMakeFiles/demangler.dir/stgrammars/borlandll .cpp.o c++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. deps/demangler/src/demangler/CMakeFiles/demangler.dir/build.make:158: recipe for target 'deps/demangl er/src/demangler/CMakeFiles/demangler.dir/stgrammars/borlandll.cpp.o' failed make[2]: *** [deps/demangler/src/demangler/CMakeFiles/demangler.dir/stgrammars/borlandll.cpp.o] Error 4 CMakeFiles/Makefile2:1932: recipe for target 'deps/demangler/src/demangler/CMakeFiles/demangler.dir/a ll' failed make[1]: *** [deps/demangler/src/demangler/CMakeFiles/demangler.dir/all] Error 2 Makefile:149: recipe for target 'all' failed make: *** [all] Error 2 % ``` Output of `gcc -v`: ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-targets=all --enable-multiarch --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18) ```
[Bug c++/83553] [6/7/8 Regression] compiler removes body of the for-loop, although there is a case label inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83553 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Dec 23 08:43:10 2017 New Revision: 255988 URL: https://gcc.gnu.org/viewcvs?rev=255988=gcc=rev Log: PR c++/83553 * fold-const.c (struct contains_label_data): New type. (contains_label_1): Return non-NULL even for CASE_LABEL_EXPR, unless inside of a SWITCH_BODY seen during the walk. (contains_label_p): Use walk_tree instead of walk_tree_without_duplicates, prepare data for contains_label_1 and provide own pset. * c-c++-common/torture/pr83553.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/c-c++-common/torture/pr83553.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/fold-const.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/83553] [6/7/8 Regression] compiler removes body of the for-loop, although there is a case label inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83553 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Dec 23 08:40:19 2017 New Revision: 255987 URL: https://gcc.gnu.org/viewcvs?rev=255987=gcc=rev Log: PR c++/83553 * fold-const.c (struct contains_label_data): New type. (contains_label_1): Return non-NULL even for CASE_LABEL_EXPR, unless inside of a SWITCH_BODY seen during the walk. (contains_label_p): Use walk_tree instead of walk_tree_without_duplicates, prepare data for contains_label_1 and provide own pset. * c-c++-common/torture/pr83553.c: New test. Added: trunk/gcc/testsuite/c-c++-common/torture/pr83553.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
