[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #27 from Jeevitha --- Jakub's patch fixed the issue on powerpc64le-linux-gnu
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Priority|P3 |P1 --- Comment #26 from Jakub Jelinek --- Fixed now.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #25 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9582538cf07d83d7e80553827de8b0f91e4705d8
commit r14-5955-g9582538cf07d83d7e80553827de8b0f91e4705d8
Author: Jakub Jelinek
Date: Wed Nov 29 09:14:03 2023 +0100
fold-mem-offsets: Fix powerpc64le-linux profiledbootstrap [PR111601]
The introduction of the fold-mem-offsets pass breaks profiledbootstrap
on powerpc64le-linux.
From what I can see, the pass works one basic block at a time and
will punt on any non-DEBUG_INSN uses outside of the current block
(I believe because of the
/* This use affects instructions outside of CAN_FOLD_INSNS. */
if (!bitmap_bit_p (_fold_insns, INSN_UID (use)))
return 0;
test and can_fold_insns only set in do_analysis (when processing insns in
current bb, cleared at the end) or results of get_single_def_in_bb
(which are checked to be in the same bb).
But, while get_single_def_in_bb checks for
if (DF_INSN_LUID (def) > DF_INSN_LUID (insn))
return NULL;
The basic block in the PR in question has:
...
(insn 212 210 215 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable
] [152]) [2 *last_viable_336+0 S8 A64])
(reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":50:17 683
{*movdi_internal64}
(expr_list:REG_DEAD (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(nil)))
(insn 215 212 484 25 (set (reg:DI 5 5 [226])
(const_int 0 [0])) "pr111601.ii":52:12 683 {*movdi_internal64}
(expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 484 215 218 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":52:12 683
{*movdi_internal64}
(nil))
...
(insn 564 214 216 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(plus:DI (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(const_int 96 [0x60]))) "pr111601.ii":52:12 66 {*adddi3}
(nil))
(insn 216 564 219 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable
] [152]) [2 _343->next+0 S8 A64])
(reg:DI 5 5 [226])) "pr111601.ii":52:12 683 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 5 5 [226])
(nil)))
...
and when asking for all uses of %r10 from def 564, it will see uses
in 216 and 212; the former is after the += 96 addition and gets changed
to load from %r10+96 with the addition being dropped, but there is
the other store which is a use across the backedge and when reached
from other edges certainly doesn't have the + 96 addition anywhere,
so the pass doesn't actually change that location.
This patch adds checks from get_single_def_in_bb to get_uses as well,
in particular check that the (regular non-debug) use only appears in the
same basic block as the definition and that it doesn't appear before it
(i.e.
use across backedge).
2023-11-29 Jakub Jelinek
PR bootstrap/111601
* fold-mem-offsets.cc (get_uses): Ignore DEBUG_INSN uses.
Otherwise,
punt if use is in a different basic block from INSN or appears
before
INSN in the same basic block. Formatting fixes.
(get_single_def_in_bb): Formatting fixes.
(fold_offsets_1, pass_fold_mem_offsets::execute): Comment
formatting
fixes.
* g++.dg/opt/pr111601.C: New test.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #24 from Jakub Jelinek --- As the pass seems to work on one basic block at the time (everything from analysis to actual changes), I wonder if e.g. get_uses shouldn't punt if it sees (non-DEBUG_INSN!) uses in other basic block but the current one (this would still not fix this wrong-code) or if the definition's luid is higher than use's luid (i.e. the use is in the same bb, but still from a different iteration of the loop). See the loop: *last_viable = c; *cand = c->next; c->next = (z_candidate *) 0; last_viable = >next; if (!*cand) break; c = *cand; goto loop; statements done in the loop body, the *last_viable = c; store is the %r9 store to %r10 (which is initially address of some automatic variable, but >next aka c + 96 for second and following iteration), the c->next = 0 store is the %r5 store to %r10 (which has been incremented by 96 first.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #23 from Jakub Jelinek --- Looking around, seems do_analysis properly finds out both uses of the %r10 += 96 - the store of %r5 later in the same bb and store of %r9 earlier in the same bb (at the start of it), and continues because both stores look to be right form and so changeable etc. But then probably later on we punt on changing the store earlier in the bb (after all, changing it would be invalid, because %r10 reachable at that point is initialized by multiple different setters and all but one don't really have that += 96 offset in them), but somehow get_uses is only done during analysis and the pass doesn't give up on changing the other spots when it had to give up changing one of the uses.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #22 from Jakub Jelinek ---
Full executable testcase:
struct tree_base
{
int code:16;
};
struct saved_scope
{
void *pad[14];
int x_processing_template_decl;
};
struct saved_scope *scope_chain;
struct z_candidate
{
tree_base *fn;
void *pad[11];
z_candidate *next;
int viable;
int flags;
};
__attribute__((noipa)) struct z_candidate *
splice_viable (struct z_candidate *cands, bool strict_p, bool *any_viable_p)
{
struct z_candidate *viable;
struct z_candidate **last_viable;
struct z_candidate **cand;
bool found_strictly_viable = false;
if (scope_chain->x_processing_template_decl)
strict_p = true;
viable = (z_candidate *) 0;
last_viable =
*any_viable_p = false;
cand =
while (*cand)
{
struct z_candidate *c = *cand;
if (!strict_p && (c->viable == 1 || ((int) (c->fn)->code) == 273))
{
strict_p = true;
if (viable && !found_strictly_viable)
{
*any_viable_p = false;
*last_viable = cands;
cands = viable;
viable = (z_candidate *) 0;
last_viable =
}
}
if (strict_p ? c->viable == 1 : c->viable)
{
*last_viable = c;
*cand = c->next;
c->next = (z_candidate *) 0;
last_viable = >next;
*any_viable_p = true;
if (c->viable == 1)
found_strictly_viable = true;
}
else
cand = >next;
}
return viable ? viable : cands;
}
int
main ()
{
saved_scope s{};
scope_chain =
z_candidate z[4] = {};
z[0].next = [1];
z[1].viable = 1;
z[1].next = [2];
z[2].viable = 1;
z[2].next = [3];
bool b;
z_candidate *c = splice_viable ([0], true, );
if (c != [1] || z[1].next != [2] || z[2].next)
__builtin_abort ();
return 0;
}
../prev-gcc/xg++ -B ../prev-gcc/ -O2 -fprofile-generate -fno-exceptions
-fno-rtti -o ~/pr111601.{s,ii} -S; g++ -o ~/pr111601{,.s}
../prev-gcc/libgcov.a; ~/pr111601; echo $?; ../prev-gcc/xg++ -B ../prev-gcc/
-O2 -fprofile-generate -fno-exceptions -fno-rtti -o ~/pr111601.{s,ii} -S
-fno-fold-mem-offsets; g++ -o ~/pr111601{,.s} ../prev-gcc/libgcov.a;
~/pr111601; echo $?
Aborted
134
0
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #21 from Jakub Jelinek ---
Reduced testcase (though, just the function in question, not a runable
testcase):
struct tree_base
{
int code:16;
};
struct saved_scope
{
void *pad[14];
int x_processing_template_decl;
};
extern struct saved_scope *scope_chain;
struct z_candidate
{
tree_base *fn;
void *pad[11];
z_candidate *next;
int viable;
int flags;
};
__attribute__((noipa)) struct z_candidate *
splice_viable (struct z_candidate *cands, bool strict_p, bool *any_viable_p)
{
struct z_candidate *viable;
struct z_candidate **last_viable;
struct z_candidate **cand;
bool found_strictly_viable = false;
if (scope_chain->x_processing_template_decl)
strict_p = true;
viable = (z_candidate *) 0;
last_viable =
*any_viable_p = false;
cand =
while (*cand)
{
struct z_candidate *c = *cand;
if (!strict_p && (c->viable == 1 || ((int) (c->fn)->code) == 273))
{
strict_p = true;
if (viable && !found_strictly_viable)
{
*any_viable_p = false;
*last_viable = cands;
cands = viable;
viable = (z_candidate *) 0;
last_viable =
}
}
if (strict_p ? c->viable == 1 : c->viable)
{
*last_viable = c;
*cand = c->next;
c->next = (z_candidate *) 0;
last_viable = >next;
*any_viable_p = true;
if (c->viable == 1)
found_strictly_viable = true;
}
else
cand = >next;
}
return viable ? viable : cands;
}
With this and
./cc1plus -quiet -fpreprocessed -O2 -fprofile-generate -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -fno-common -fno-PIE -mcpu=power8
pr111601.ii -o pr111601.s3 -ffold-mem-offsets -da
vs.
./cc1plus -quiet -fpreprocessed -O2 -fprofile-generate -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -fno-common -fno-PIE -mcpu=power8
pr111601.ii -o pr111601.s4 -fno-fold-mem-offsets -da
the assembly difference is just
.L13:
std 9,0(10)
mr 10,9
li 5,0
+ addi 10,10,96
li 7,1
addi 4,4,1
addi 6,6,1
ld 9,96(9)
std 9,0(8)
- std 5,96(10)
+ std 5,0(10)
stb 7,0(31)
ori 2,2,0
ld 9,0(8)
cmpdi 0,9,0
beq 0,.L18
lwz 7,104(9)
li 12,1
li 5,1
cmpwi 0,7,1
beq 0,.L13
which shows the problem in a single loop. Without the pass, %r10 is set to %r9
+ 96 and 5 (NULL) is stored to it first and if the loop loops again, 9 is
stored to it. While with the pass, %r10 is set to %r9, 5 (NULL) is stored to
%r10 + 96 and then next iteration overwrites the fn pointer in the structure
rather than next.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #20 from Jakub Jelinek --- Manolis/Jeff, how does the pass prove that it found and adjusted all the uses of the register rather than just some (or the first one) as apparently happens on this testcase?
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #19 from Jakub Jelinek ---
When using current trunk (r14-5889), I can see it even in x86_64-linux ->
powerpc64le-linux cross-compiler.
diff -U300 pr111601.s{1,2}
will show
std 9,0(10)
mr 10,9
+ addi 10,10,96
li 26,0
- li 28,0
ld 7,.LANCHOR0+136@toc@l(11)
+ li 28,0
addi 6,6,1
addi 12,12,1
addi 7,7,1
ld 9,96(9)
std 7,.LANCHOR0+136@toc@l(11)
li 11,0
li 7,1
std 9,0(8)
- std 11,96(10)
+ std 11,0(10)
stb 7,0(5)
- ori 2,2,0
ld 9,0(8)
cmpdi 0,9,0
bne 0,.L104
.p2align 4,,15
and earlier
.L104:
lwz 7,104(9)
li 11,1
li 29,1
cmpwi 0,7,1
b .L54
and even earlier
.L54:
beq 0,.L48
and
.L48:
std 9,0(10)
mr 10,9
li 11,0
+ addi 10,10,96
li 7,1
addi 6,6,1
addi 12,12,1
ld 9,96(9)
std 9,0(8)
- std 11,96(10)
+ std 11,0(10)
which is where the r10 value which with -fno-fold-mem-offsets was modified with
the 96 addend and with -ffold-mem-offsets no longer is is used without on the
std 9,0(10) store and because that store wasn't adjusted, it stores into
incorrect spot.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #18 from Jakub Jelinek --- Created attachment 56697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56697=edit pr111601.ii.xz Preprocessed source, compile with ./cc1plus -quiet -fpreprocessed -O2 -fprofile-generate -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -fno-PIE -mcpu=power8 pr111601.ii -o pr111601.s1 and ./cc1plus -quiet -fpreprocessed -O2 -fprofile-generate -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -fno-PIE -mcpu=power8 pr111601.ii -o pr111601.s2 -fno-fold-mem-offsets
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #17 from Jakub Jelinek --- And under a debugger I can see exactly that happening. With the bad version of splice_viable on the 16th call of splice_viable, I see the code path in which r10 in the last hunk's spot where the addi r10,r10,96 from the second hunk was previously removed and the 0x10424860 store changed into std r11,96(r10) from std r11,0(r10) eventually reaches 0x10424724 store which consumed previously the store of r10 with 96 added to it but now just 0: (gdb) disas 0x10424860,0x10424878 Dump of assembler code from 0x10424860 to 0x10424878: 0x10424860 <_ZL13splice_viableP11z_candidatebPb+864>:std r11,96(r10) 0x10424864 <_ZL13splice_viableP11z_candidatebPb+868>:stb r7,0(r5) 0x10424868 <_ZL13splice_viableP11z_candidatebPb+872>:ori r2,r2,0 0x1042486c <_ZL13splice_viableP11z_candidatebPb+876>:ld r9,0(r8) 0x10424870 <_ZL13splice_viableP11z_candidatebPb+880>:cmpdi r9,0 0x10424874 <_ZL13splice_viableP11z_candidatebPb+884>:bne 0x1042475c <_ZL13splice_viableP11z_candidatebPb+604> End of assembler dump. (gdb) disas 0x1042475c,0x10424770 Dump of assembler code from 0x1042475c to 0x10424770: 0x1042475c <_ZL13splice_viableP11z_candidatebPb+604>:lwz r7,104(r9) 0x10424760 <_ZL13splice_viableP11z_candidatebPb+608>:li r11,1 0x10424764 <_ZL13splice_viableP11z_candidatebPb+612>:li r29,1 0x10424768 <_ZL13splice_viableP11z_candidatebPb+616>:cmpwi r7,1 0x1042476c <_ZL13splice_viableP11z_candidatebPb+620>:b 0x104246fc <_ZL13splice_viableP11z_candidatebPb+508> End of assembler dump. (gdb) disas 0x104246fc,0x10424700 Dump of assembler code from 0x104246fc to 0x10424700: 0x104246fc <_ZL13splice_viableP11z_candidatebPb+508>:beq 0x10424724 <_ZL13splice_viableP11z_candidatebPb+548> End of assembler dump. (gdb) disas 0x10424724,0x10424728 Dump of assembler code from 0x10424724 to 0x10424728: => 0x10424724 <_ZL13splice_viableP11z_candidatebPb+548>:std r9,0(r10) End of assembler dump. In the assembly, this corresponds to first jumping on non-equal to .L104 label, then to .L54 label, and then immediately on non-equal to .L48 label.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #16 from Jakub Jelinek --- oris 2,2,0 is a noop group_ending_nop. Anyway, that oris 2,2,0 nor the li 28, 0 scheduling don't change anything and I've narrowed it down (- bad, + working) to the --- cp/call.s 2023-11-27 14:24:12.616613833 + +++ cp/call.s 2023-11-27 15:08:47.345457528 + @@ -364,12 +364,13 @@ _ZL13splice_viableP11z_candidatebPb: std 9,0(10) mr 10,9 li 11,0 + addi 10,10,96 li 7,1 addi 6,6,1 addi 12,12,1 ld 9,96(9) std 9,0(8) - std 11,96(10) + std 11,0(10) stb 7,0(5) ori 2,2,0 ld 9,0(8) @@ -448,6 +449,7 @@ _ZL13splice_viableP11z_candidatebPb: .cfi_restore 25 std 9,0(10) mr 10,9 + addi 10,10,96 li 26,0 li 28,0 ld 7,.LANCHOR0+136@toc@l(11) @@ -459,7 +461,7 @@ _ZL13splice_viableP11z_candidatebPb: li 11,0 li 7,1 std 9,0(8) - std 11,96(10) + std 11,0(10) stb 7,0(5) ori 2,2,0 ld 9,0(8) changes so far. So I bet 10 must be somewhere live after those stores. Reverting further either the first or second two hunks breaks it again.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #15 from Jakub Jelinek --- Looking at the assembly difference, I see just a few functions: --- cp/call.s2 2023-11-27 13:40:15.088908624 + +++ cp/call.s1 2023-11-27 13:35:56.912298399 + @@ -364,13 +364,12 @@ _ZL13splice_viableP11z_candidatebPb: std 9,0(10) mr 10,9 li 11,0 - addi 10,10,96 li 7,1 addi 6,6,1 addi 12,12,1 ld 9,96(9) std 9,0(8) - std 11,0(10) + std 11,96(10) stb 7,0(5) ori 2,2,0 ld 9,0(8) @@ -449,10 +448,9 @@ _ZL13splice_viableP11z_candidatebPb: .cfi_restore 25 std 9,0(10) mr 10,9 - addi 10,10,96 li 26,0 - ld 7,.LANCHOR0+136@toc@l(11) li 28,0 + ld 7,.LANCHOR0+136@toc@l(11) addi 6,6,1 addi 12,12,1 addi 7,7,1 @@ -461,8 +459,9 @@ _ZL13splice_viableP11z_candidatebPb: li 11,0 li 7,1 std 9,0(8) - std 11,0(10) + std 11,96(10) stb 7,0(5) + ori 2,2,0 ld 9,0(8) cmpdi 0,9,0 bne 0,.L104 @@ -21377,24 +21376,22 @@ _ZN2wi5lts_pI16generic_wide_intINS_13ext nop addis 10,2,.LANCHOR0+5848@toc@ha mr 5,30 - addi 29,1,64 ld 9,.LANCHOR0+5848@toc@l(10) - std 3,0(29) + std 3,64(1) addi 3,1,48 - std 4,8(29) + std 4,72(1) lis 4,0x2 addi 9,9,1 std 9,.LANCHOR0+5848@toc@l(10) bl _ZN2wi10int_traitsI16generic_wide_intINS_13extended_treeILi131072E9decomposeEPljRKS4_ nop - addi 9,1,32 lwz 30,72(1) ld 29,64(1) rldicl 7,4,0,32 + std 3,32(1) + std 4,40(1) mr 6,3 cmplwi 0,7,1 - std 3,0(9) - std 4,8(9) beq 0,.L2422 addis 10,2,.LANCHOR0+5912@toc@ha rldicl 4,30,0,32 @@ -51700,10 +51697,9 @@ _ZL8op_errorRK13op_location_t9tree_codeS addis 7,2,.LC1285@toc@ha ld 7,.LC1285@toc@l(7) lbzx 10,10,5 - addi 10,10,58 sldi 10,10,5 add 10,7,10 - ld 29,8(10) + ld 29,1864(10) .L6276: cmpdi 0,30,0 beq 0,.L6338 @@ -172014,7 +172010,7 @@ __gcov7._Z15good_conversionP9tree_nodeS0 .long 1110716448 .zero 4 .quad 0 - .long 285183267 + .long 284929938 .long 1725772321 .quad .LC2647 .quad __gcov_merge_add While most of the changes look reasonable (but I haven't so far verified if the removed additions turned into memory immediates set registers which aren't used in other places), the addition of ori 2,2,0 instruction seems kind of unexpected.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #14 from Jakub Jelinek --- So, indeed adding -fno-fold-memory-offsets fixes it: /home/jakub/gcc/obj94/./prev-gcc/xg++ -B/home/jakub/gcc/obj94/./prev-gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/jakub/gcc/libstdc++-v3/libsupc++ -L/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Icp -I../../gcc -I../../gcc/cp -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -o cp/call.o ../../gcc/cp/call.cc; make cc1plus; pushd ../powerpc64le-unknown-linux-gnu/libstdc++-v3/include; /home/jakub/gcc/obj94/./gcc/xgcc -shared-libgcc -B/home/jakub/gcc/obj94/./gcc -nostdinc++ -L/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/src -L/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem /usr/local/powerpc64le-unknown-linux-gnu/include -isystem /usr/local/powerpc64le-unknown-linux-gnu/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/jakub/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/jakub/gcc/libstdc++-v3/include/precompiled/stdc++.h -o powerpc64le-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch; popd if [ -f ../stage_final ] \ && cmp -s ../stage_current ../stage_final; then \ cp ../prev-gcc/cc1plus-checksum.cc cc1plus-checksum.cc; \ else \ build/genchecksum cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/contracts.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/mapper-client.o cp/mapper-resolver.o cp/method.o cp/module.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o glibc-c.o rs6000-c.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcody/libcody.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../libbacktrace/.libs/libbacktrace.a \ checksum-options > cc1plus-checksum.cc.tmp && \ ../../gcc/../move-if-change cc1plus-checksum.cc.tmp cc1plus-checksum.cc; \ fi /home/jakub/gcc/obj94/./prev-gcc/xg++ -B/home/jakub/gcc/obj94/./prev-gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/jakub/gcc/libstdc++-v3/libsupc++ -L/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/jakub/gcc/obj94/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -fprofile-generate -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #13 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #12) > On Mon, 27 Nov 2023, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 > > > > --- Comment #11 from Jakub Jelinek --- > > r14-4662 still builds ok and r14-4668 fails, wonder which of those commits > > it > > is. > > My bet is r14-4664-g04c9cf5c786b94 That is my guess as well, but because the new pass is enabled at -O2 and above only and stage1 is built with -O0, it wouldn't then be related to jump threading but this new RTL optimization. Anyway, once my current r14-4665 build finishes or fails, I'll try to rebuild cp/call.o with -fno-fold-mem-offsets and see what I get to.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #12 from rguenther at suse dot de --- On Mon, 27 Nov 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 > > --- Comment #11 from Jakub Jelinek --- > r14-4662 still builds ok and r14-4668 fails, wonder which of those commits it > is. My bet is r14-4664-g04c9cf5c786b94
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #11 from Jakub Jelinek --- r14-4662 still builds ok and r14-4668 fails, wonder which of those commits it is.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #10 from Jakub Jelinek --- With the above commands, r14-4258 ICEs in libcody build, r14-4650 builds ok, r14-4846, r14-5043, r14-5829 ICE during the PCH libstdc++ compilation, will continue bisecting that.
