* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
@ 2023-09-26 17:15 ` pinskia at gcc dot gnu.org
2023-10-17 2:11 ` bergner at gcc dot gnu.org
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-09-26 17:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
Keywords| |build, ice-on-valid-code
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
2023-09-26 17:15 ` [Bug bootstrap/111601] " pinskia at gcc dot gnu.org
@ 2023-10-17 2:11 ` bergner at gcc dot gnu.org
2023-10-18 13:31 ` doko at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-10-17 2:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bergner at gcc dot gnu.org
--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
Did you see the same error on both x86_64 and powerpc64le? ...and what
configure options did you use on powerpc64le-linux?
When I do a normal configure and make profiledbootstrap-lean on
powerpc64le-linux, I see instead:
In file included from
/home/bergner/gcc/gcc-fsf-mainline-pr111601/libstdc++-v3/include/precompiled/stdc++.h:42:
/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest-2/powerpc64le-linux/libstdc++-v3/include/cstdlib:
In function ‘ldiv_t std::div(long int, long int)’:
/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest-2/powerpc64le-linux/libstdc++-v3/include/cstdlib:181:57:
internal compiler error: tree check: expected tree that contains ‘decl common’
structure, have ‘<invalid tree code>’ in build_new_method_call, at
cp/call.cc:11630
181 | div(long __i, long __j) _GLIBCXX_NOTHROW { return ldiv(__i, __j); }
| ~~~~^~~~~~~~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
make[5]: *** [Makefile:1925:
powerpc64le-linux/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
make[5]: Leaving directory
'/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest-2/powerpc64le-linux/libstdc++-v3/include'
make[4]: *** [Makefile:576: all-recursive] Error 1
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
2023-09-26 17:15 ` [Bug bootstrap/111601] " pinskia at gcc dot gnu.org
2023-10-17 2:11 ` bergner at gcc dot gnu.org
@ 2023-10-18 13:31 ` doko at gcc dot gnu.org
2023-10-18 19:48 ` bergner at gcc dot gnu.org
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: doko at gcc dot gnu.org @ 2023-10-18 13:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Matthias Klose <doko at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|powerpc64le-linux |powerpc64le-linux
|x86_64-linux |
--- Comment #2 from Matthias Klose <doko at gcc dot gnu.org> ---
this seems to be fixed on x86_64-linux-gnu with trunk 20231017.
powerpc64le-linux now fails in a different way, trying to build the libstdc++
pch headers.
Full build log at
https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=ppc64el&ver=1%3A20231017-1&stamp=1697561774&raw=1
Configured with: -v
--with-pkgversion='Debian 20231017-1'
--with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs'
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr/lib/gcc-snapshot
--with-gcc-major-version-only
--program-prefix=
--enable-shared
--enable-linker-build-id
--disable-nls
--enable-bootstrap
--enable-clocale=gnu
--enable-libstdcxx-debug
--enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new
--enable-gnu-unique-object
--enable-plugin
--with-system-zlib
--enable-libphobos-checking=release
--with-target-system-zlib=auto
--with-libphobos-druntime-only=yes
--enable-objc-gc=auto
--enable-secureplt
--enable-targets=powerpcle-linux
--disable-multilib
--enable-multiarch
--disable-werror
--with-long-double-128
--enable-offload-targets=nvptx-none=/<<PKGBUILDDIR>>/debian/tmp-nvptx/usr/lib/gcc-snapshot
--enable-offload-defaulted
--without-cuda-driver
--enable-checking=yes,extra,rtl
--build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu
--with-build-config=bootstrap-lto-lean
--enable-link-serialization=4
Build target is profiledbootstrap-lean
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (2 preceding siblings ...)
2023-10-18 13:31 ` doko at gcc dot gnu.org
@ 2023-10-18 19:48 ` bergner at gcc dot gnu.org
2023-10-18 20:41 ` bergner at gcc dot gnu.org
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-10-18 19:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-10-18
--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Matthias Klose from comment #2)
> this seems to be fixed on x86_64-linux-gnu with trunk 20231017.
> powerpc64le-linux now fails in a different way, trying to build the
> libstdc++ pch headers.
>
> Full build log at
> https://buildd.debian.org/status/fetch.php?pkg=gcc-
> snapshot&arch=ppc64el&ver=1%3A20231017-1&stamp=1697561774&raw=1
Ok, that is the same error I'm seeing, so Confirmed. I'll try and see if I can
reduce the test case.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (3 preceding siblings ...)
2023-10-18 19:48 ` bergner at gcc dot gnu.org
@ 2023-10-18 20:41 ` bergner at gcc dot gnu.org
2023-10-18 20:53 ` pinskia at gcc dot gnu.org
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-10-18 20:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #3)
> I'll try and see if I can reduce the test case.
cvise reduced this down to:
bergner@ltcden2-lp1:$ cat pr111601.ii
struct param_type {
param_type() : param_type(0.5) { }
param_type(double);
};
bergner@ltcden2-lp1:$
/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr111601-regtest/./gcc
-shared-libgcc -fno-checking -x c++-header -nostdinc++ -O2 -S pr111601.ii
pr111601.ii: In constructor ‘param_type::param_type()’:
pr111601.ii:2:32: internal compiler error: tree check: expected tree that
contains ‘decl common’ structure, have ‘<invalid tree code>’ in
build_new_method_call, at cp/call.cc:11630
2 | param_type() : param_type(0.5) { }
| ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
I'll note that a xgcc built without using "make profiledbootstrap-lean" does
not ICE.
CCing richi and jakub to see if they've seen anything like this before?
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (4 preceding siblings ...)
2023-10-18 20:41 ` bergner at gcc dot gnu.org
@ 2023-10-18 20:53 ` pinskia at gcc dot gnu.org
2023-10-18 21:26 ` bergner at gcc dot gnu.org
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-18 20:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #4)
> CCing richi and jakub to see if they've seen anything like this before?
I suspect we are miscompiling the final compiler somehow. I linked 2 other
reports which reported that PGO is causing wrong code; I have not looked into
confirming them yet though.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (5 preceding siblings ...)
2023-10-18 20:53 ` pinskia at gcc dot gnu.org
@ 2023-10-18 21:26 ` bergner at gcc dot gnu.org
2023-10-19 6:23 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-10-18 21:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Peter Bergner from comment #4)
> > CCing richi and jakub to see if they've seen anything like this before?
>
> I suspect we are miscompiling the final compiler somehow. I linked 2 other
> reports which reported that PGO is causing wrong code; I have not looked
> into confirming them yet though.
Thanks and yes, I agree. Luckily those test cases are MUCH smaller than gcc
itself. Hopefully the bug is the same!
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (6 preceding siblings ...)
2023-10-18 21:26 ` bergner at gcc dot gnu.org
@ 2023-10-19 6:23 ` rguenth at gcc dot gnu.org
2023-11-17 5:33 ` jeevitha at gcc dot gnu.org
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-19 6:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'd say we probably miscompile cp/call.cc:tourney - you could try marking that
noinline (or verify whether it has been inlined). There's some wrong-code
bugs related to the loop header copying changes (also profile related) and
also loop-splitting.
I suspect bisecting will end up in a related area.
Most helpful would really be to bisect this.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (7 preceding siblings ...)
2023-10-19 6:23 ` rguenth at gcc dot gnu.org
@ 2023-11-17 5:33 ` jeevitha at gcc dot gnu.org
2023-11-24 19:59 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jeevitha at gcc dot gnu.org @ 2023-11-17 5:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Jeevitha <jeevitha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeevitha at gcc dot gnu.org
--- Comment #8 from Jeevitha <jeevitha at gcc dot gnu.org> ---
When I disable thread-jumps for cp/call.cc:splice_viable. There is no bootstrap
fail. thread-jumps optimisation was enabled in O2 level.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (8 preceding siblings ...)
2023-11-17 5:33 ` jeevitha at gcc dot gnu.org
@ 2023-11-24 19:59 ` jakub at gcc dot gnu.org
2023-11-26 21:36 ` [Bug bootstrap/111601] [14 Regression] profilebootstrap " jakub at gcc dot gnu.org
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-24 19:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reproduced on powerpc64le-linux with just
../configure --enable-languages=c,c++ --enable-checking=yes,rtl,extra
--disable-libsanitizer --with-long-double-128; make -j160 profiledbootstrap
so fortunately doesn't need LTO bootstrap.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (9 preceding siblings ...)
2023-11-24 19:59 ` jakub at gcc dot gnu.org
@ 2023-11-26 21:36 ` jakub at gcc dot gnu.org
2023-11-27 11:37 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-26 21:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (10 preceding siblings ...)
2023-11-26 21:36 ` [Bug bootstrap/111601] [14 Regression] profilebootstrap " jakub at gcc dot gnu.org
@ 2023-11-27 11:37 ` jakub at gcc dot gnu.org
2023-11-27 12:24 ` rguenther at suse dot de
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 11:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
r14-4662 still builds ok and r14-4668 fails, wonder which of those commits it
is.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (11 preceding siblings ...)
2023-11-27 11:37 ` jakub at gcc dot gnu.org
@ 2023-11-27 12:24 ` rguenther at suse dot de
2023-11-27 12:27 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenther at suse dot de @ 2023-11-27 12:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #12 from rguenther at suse dot de <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 <jakub at gcc dot gnu.org> ---
> r14-4662 still builds ok and r14-4668 fails, wonder which of those commits it
> is.
My bet is r14-4664-g04c9cf5c786b94
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (12 preceding siblings ...)
2023-11-27 12:24 ` rguenther at suse dot de
@ 2023-11-27 12:27 ` jakub at gcc dot gnu.org
2023-11-27 13:31 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 12:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@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 <jakub at gcc dot gnu.org> ---
> > 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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (13 preceding siblings ...)
2023-11-27 12:27 ` jakub at gcc dot gnu.org
@ 2023-11-27 13:31 ` jakub at gcc dot gnu.org
2023-11-27 13:51 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 13:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 -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. -I.
-I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libcody -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace
-o cc1plus-checksum.o -MT cc1plus-checksum.o -MMD -MP -MF
./.deps/cc1plus-checksum.TPo cc1plus-checksum.cc
/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
-no-pie -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 -no-pie -static-libstdc++ -static-libgcc -o cc1plus \
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 cc1plus-checksum.o libbackend.a
main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcody/libcody.a \
libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp
-rdynamic -ldl -L./../zlib -lz
~/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/include ~/gcc/obj94/gcc
In file included from
/home/jakub/gcc/libstdc++-v3/include/precompiled/stdc++.h:42:
/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:
In function ‘ldiv_t std::div(long int, long int)’:
/home/jakub/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:181:57:
internal compiler error: tree check: expected tree that contains ‘decl common’
structure, have ‘<invalid tree code>’ in build_new_method_call, at
cp/call.cc:11630
181 | div(long __i, long __j) _GLIBCXX_NOTHROW { return ldiv(__i, __j); }
| ~~~~^~~~~~~~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
~/gcc/obj94/gcc
[jakub@gcc2-power8 gcc]$ /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
-fno-fold-mem-offsets; 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 -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. -I.
-I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libcody -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace
-o cc1plus-checksum.o -MT cc1plus-checksum.o -MMD -MP -MF
./.deps/cc1plus-checksum.TPo cc1plus-checksum.cc
/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
-no-pie -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 -no-pie -static-libstdc++ -static-libgcc -o cc1plus \
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 cc1plus-checksum.o libbackend.a
main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcody/libcody.a \
libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp
-rdynamic -ldl -L./../zlib -lz
~/gcc/obj94/powerpc64le-unknown-linux-gnu/libstdc++-v3/include ~/gcc/obj94/gcc
~/gcc/obj94/gcc
Guess will now try to bisect on which function the problem is.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (14 preceding siblings ...)
2023-11-27 13:31 ` jakub at gcc dot gnu.org
@ 2023-11-27 13:51 ` jakub at gcc dot gnu.org
2023-11-27 15:14 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 13:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at the assembly difference, I see just a few functions:
--- cp/call.s2 2023-11-27 13:40:15.088908624 +0000
+++ cp/call.s1 2023-11-27 13:35:56.912298399 +0000
@@ -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_treeILi131072EEEEE9decomposeEPljRKS4_
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (15 preceding siblings ...)
2023-11-27 13:51 ` jakub at gcc dot gnu.org
@ 2023-11-27 15:14 ` jakub at gcc dot gnu.org
2023-11-27 16:21 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 15:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 +0000
+++ cp/call.s 2023-11-27 15:08:47.345457528 +0000
@@ -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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (16 preceding siblings ...)
2023-11-27 15:14 ` jakub at gcc dot gnu.org
@ 2023-11-27 16:21 ` jakub at gcc dot gnu.org
2023-11-27 16:45 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 16:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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
0x0000000010424860 store changed into std r11,96(r10) from std r11,0(r10)
eventually reaches 0x0000000010424724 store which
consumed previously the store of r10 with 96 added to it but now just 0:
(gdb) disas 0x0000000010424860,0x0000000010424878
Dump of assembler code from 0x10424860 to 0x10424878:
0x0000000010424860 <_ZL13splice_viableP11z_candidatebPb+864>: std
r11,96(r10)
0x0000000010424864 <_ZL13splice_viableP11z_candidatebPb+868>: stb
r7,0(r5)
0x0000000010424868 <_ZL13splice_viableP11z_candidatebPb+872>: ori
r2,r2,0
0x000000001042486c <_ZL13splice_viableP11z_candidatebPb+876>: ld
r9,0(r8)
0x0000000010424870 <_ZL13splice_viableP11z_candidatebPb+880>: cmpdi
r9,0
0x0000000010424874 <_ZL13splice_viableP11z_candidatebPb+884>: bne
0x1042475c <_ZL13splice_viableP11z_candidatebPb+604>
End of assembler dump.
(gdb) disas 0x1042475c,0x0000000010424770
Dump of assembler code from 0x1042475c to 0x10424770:
0x000000001042475c <_ZL13splice_viableP11z_candidatebPb+604>: lwz
r7,104(r9)
0x0000000010424760 <_ZL13splice_viableP11z_candidatebPb+608>: li
r11,1
0x0000000010424764 <_ZL13splice_viableP11z_candidatebPb+612>: li
r29,1
0x0000000010424768 <_ZL13splice_viableP11z_candidatebPb+616>: cmpwi
r7,1
0x000000001042476c <_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:
0x00000000104246fc <_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:
=> 0x0000000010424724 <_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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (17 preceding siblings ...)
2023-11-27 16:21 ` jakub at gcc dot gnu.org
@ 2023-11-27 16:45 ` jakub at gcc dot gnu.org
2023-11-27 16:57 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 56697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56697&action=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
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (18 preceding siblings ...)
2023-11-27 16:45 ` jakub at gcc dot gnu.org
@ 2023-11-27 16:57 ` jakub at gcc dot gnu.org
2023-11-27 17:01 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 16:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (19 preceding siblings ...)
2023-11-27 16:57 ` jakub at gcc dot gnu.org
@ 2023-11-27 17:01 ` jakub at gcc dot gnu.org
2023-11-27 18:33 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 17:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (20 preceding siblings ...)
2023-11-27 17:01 ` jakub at gcc dot gnu.org
@ 2023-11-27 18:33 ` jakub at gcc dot gnu.org
2023-11-27 19:24 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 18:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 = &viable;
*any_viable_p = false;
cand = &cands;
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 = &viable;
}
}
if (strict_p ? c->viable == 1 : c->viable)
{
*last_viable = c;
*cand = c->next;
c->next = (z_candidate *) 0;
last_viable = &c->next;
*any_viable_p = true;
if (c->viable == 1)
found_strictly_viable = true;
}
else
cand = &c->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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (21 preceding siblings ...)
2023-11-27 18:33 ` jakub at gcc dot gnu.org
@ 2023-11-27 19:24 ` jakub at gcc dot gnu.org
2023-11-27 20:02 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 19:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 = &viable;
*any_viable_p = false;
cand = &cands;
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 = &viable;
}
}
if (strict_p ? c->viable == 1 : c->viable)
{
*last_viable = c;
*cand = c->next;
c->next = (z_candidate *) 0;
last_viable = &c->next;
*any_viable_p = true;
if (c->viable == 1)
found_strictly_viable = true;
}
else
cand = &c->next;
}
return viable ? viable : cands;
}
int
main ()
{
saved_scope s{};
scope_chain = &s;
z_candidate z[4] = {};
z[0].next = &z[1];
z[1].viable = 1;
z[1].next = &z[2];
z[2].viable = 1;
z[2].next = &z[3];
bool b;
z_candidate *c = splice_viable (&z[0], true, &b);
if (c != &z[1] || z[1].next != &z[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
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (22 preceding siblings ...)
2023-11-27 19:24 ` jakub at gcc dot gnu.org
@ 2023-11-27 20:02 ` jakub at gcc dot gnu.org
2023-11-27 20:17 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 20:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (23 preceding siblings ...)
2023-11-27 20:02 ` jakub at gcc dot gnu.org
@ 2023-11-27 20:17 ` jakub at gcc dot gnu.org
2023-11-29 8:18 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-27 20:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 = &c->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 &c->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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (24 preceding siblings ...)
2023-11-27 20:17 ` jakub at gcc dot gnu.org
@ 2023-11-29 8:18 ` cvs-commit at gcc dot gnu.org
2023-11-29 8:31 ` jakub at gcc dot gnu.org
2023-11-30 17:20 ` jeevitha at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-29 8:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #25 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:9582538cf07d83d7e80553827de8b0f91e4705d8
commit r14-5955-g9582538cf07d83d7e80553827de8b0f91e4705d8
Author: Jakub Jelinek <jakub@redhat.com>
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 (&can_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 <jakub@redhat.com>
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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (25 preceding siblings ...)
2023-11-29 8:18 ` cvs-commit at gcc dot gnu.org
@ 2023-11-29 8:31 ` jakub at gcc dot gnu.org
2023-11-30 17:20 ` jeevitha at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-29 8:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Priority|P3 |P1
--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed now.
^ permalink raw reply [flat|nested] 29+ messages in thread* [Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
2023-09-26 15:27 [Bug bootstrap/111601] New: [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu doko at gcc dot gnu.org
` (26 preceding siblings ...)
2023-11-29 8:31 ` jakub at gcc dot gnu.org
@ 2023-11-30 17:20 ` jeevitha at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: jeevitha at gcc dot gnu.org @ 2023-11-30 17:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #27 from Jeevitha <jeevitha at gcc dot gnu.org> ---
Jakub's patch fixed the issue on powerpc64le-linux-gnu
^ permalink raw reply [flat|nested] 29+ messages in thread