[Bug tree-optimization/106438] powerpc: ICE when building libgfortran with -flto: in insert_value_copy_on_edge, at tree-outof-ssa.cc:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438 --- Comment #3 from Matheus Castanho --- Created attachment 53350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53350&action=edit Failing command The failing command is the final link command to create libgfortran.so, so it's rather long. I'm attaching it to the bug as a txt file, along with some warnings that gcc emitted.
[Bug libfortran/106438] powerpc: ICE when building libgfortran with -flto: in insert_value_copy_on_edge, at tree-outof-ssa.cc:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438 --- Comment #1 from Matheus Castanho --- Small typo: I meant -flto, not -lto. The patch is OK though.
[Bug libfortran/106438] New: powerpc: ICE when building libgfortran with -lto: in insert_value_copy_on_edge, at tree-outof-ssa.cc:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438 Bug ID: 106438 Summary: powerpc: ICE when building libgfortran with -lto: in insert_value_copy_on_edge, at tree-outof-ssa.cc:334 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: msc at linux dot ibm.com Target Milestone: --- Compiling libgfortran with -lto (see small patch [1] below) is failing on powerpc64le (testd on P10, but may apply to older processors as well) with current trunk: $ git gcc-descr HEAD r12-10142-ga6efab5fbc468b $ cd ~/build/gcc/ && ~/AT/pr2981/build/sources/gcc/configure --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu --cache-file=configparms --prefix=/home/mscastanho/usr --with-long-double-128 --enable-secureplt --disable-multilib --enable-threads=posix --enable-languages=fortran --disable-bootstrap --enable-__cxa_atexit --enable-shared --enable-checking=release --enable-gnu-indirect-function --enable-lto --enable-linker-build-id --without-ppl --without-cloog --without-libelf --with-system-zlib --with-cpu=power10 --with-tune=power10 && make -j60 &> _make; echo $? Error: during RTL pass: expand /home/mscastanho/AT/pr2981/build/sources/gcc/libgfortran/generated/maxloc0_4_r17.c: In function 'maxloc0_4_r17': /home/mscastanho/AT/pr2981/build/sources/gcc/libgfortran/generated/maxloc0_4_r17.c:38:1: internal compiler error: in insert_value_copy_on_edge, at tree-outof-ssa.cc:334 38 | maxloc0_4_r17 (gfc_array_i4 * const restrict retarray, | ^ 0x108ea89b insert_value_copy_on_edge /home/mscastanho/AT/pr2981/build/sources/gcc/gcc/tree-outof-ssa.cc:334 0x108ea89b eliminate_phi /home/mscastanho/AT/pr2981/build/sources/gcc/gcc/tree-outof-ssa.cc:785 0x108ea89b expand_phi_nodes(ssaexpand*) /home/mscastanho/AT/pr2981/build/sources/gcc/gcc/tree-outof-ssa.cc:1024 0x10252a1f execute /home/mscastanho/AT/pr2981/build/sources/gcc/gcc/cfgexpand.cc:6799 Git bisect is pointing to this commit: commit 133d0d422ebd18dbd215cfa5394aff9f938e7060 Author: Jakub Jelinek Date: Tue Jun 28 13:05:28 2022 +0200 fortran, libgfortran: Avoid using libquadmath for glibc 2.26+ [1] https://raw.githubusercontent.com/powertechpreview/powertechpreview/0be24b142a81e44ac4abadb3fde4eb0010b79f70/GCC%20PowerPC%20Backport/9/gcc-9-lto.patch
[Bug c++/105956] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956 --- Comment #3 from Matheus Castanho --- Sorry, looks like the original file was too large and didn't get attached when I created the bug. I attached a gzip compressed version now.
[Bug c++/105956] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956 --- Comment #2 from Matheus Castanho --- Created attachment 53129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53129&action=edit pre-processed source generated by -freport-bug
[Bug c++/105956] New: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956 Bug ID: 105956 Summary: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msc at linux dot ibm.com Target Milestone: --- Bumped into this error while compiling boost.fiber with upstream GCC: $ git gcc-descr HEAD r12-9379-g1158fe43407568 $ "/tmp/gcc-install/bin/gcc" -freport-bug -fvisibility-inlines-hidden -fPIC -m64 -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_FIBERS_DYN_LINK=1 -DBOOST_FIBERS_SOURCE -DBOOST_FILESYSTEM_DYN_LINK=1 -I"../../.." -c -o "../../../bin.v2/libs/fiber/build/gcc-custom/debug/threading-multi/visibility-hidden/scheduler.o" "../../../libs/fiber/src/scheduler.cpp" In file included from ../../../boost/intrusive/options.hpp:19, from ../../../boost/intrusive/list_hook.hpp:22, from ../../../boost/intrusive/list.hpp:20, from ../../../boost/fiber/scheduler.hpp:17, from ../../../libs/fiber/src/scheduler.cpp:7: ../../../boost/intrusive/pack_options.hpp: In instantiation of ‘struct boost::intrusive::invert_typelist_impl, &boost::fibers::waker_with_hook::waker_queue_hook_>, boost::intrusive::constant_time_size, boost::intrusive::cache_last >, boost::intrusive::index_tuple<0, 1, 2, 3> >’: ../../../boost/intrusive/pack_options.hpp:190:71: required from ‘struct boost::intrusive::invert_typelist, &boost::fibers::waker_with_hook::waker_queue_hook_>, boost::intrusive::constant_time_size, boost::intrusive::cache_last > >’ ../../../boost/intrusive/pack_options.hpp:230:55: required from ‘struct boost::intrusive::pack_options, &boost::fibers::waker_with_hook::waker_queue_hook_>, boost::intrusive::constant_time_size, boost::intrusive::cache_last >’ ../../../boost/intrusive/slist.hpp:2149:15: required from ‘struct boost::intrusive::make_slist, &boost::fibers::waker_with_hook::waker_queue_hook_>, boost::intrusive::constant_time_size, boost::intrusive::cache_last >’ ../../../boost/intrusive/slist.hpp:2173:7: required from ‘class boost::intrusive::slist, &boost::fibers::waker_with_hook::waker_queue_hook_>, boost::intrusive::constant_time_size, boost::intrusive::cache_last >’ ../../../boost/fiber/waker.hpp:73:36: required from here ../../../boost/intrusive/pack_options.hpp:164:29: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819 164 |static const std::size_t last_idx = sizeof_typelist::value - 1; | ^~~~ 0x6ec942 iterative_hash_template_arg(tree_node*, unsigned int) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:1819 0xb105c5 iterative_hash_template_arg(tree_node*, unsigned int) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:1829 0xb10fc8 hash_tmpl_and_args /home/mscastanho/dev/gcc/gcc/cp/pt.cc:1769 0xb10fc8 spec_hasher::hash(tree_node*, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:1776 0xb3389b tsubst_decl /home/mscastanho/dev/gcc/gcc/cp/pt.cc:14991 0xb26d87 tsubst_copy /home/mscastanho/dev/gcc/gcc/cp/pt.cc:17066 0xb2a720 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:21390 0xb2a2f6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:20434 0xb2bb15 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:20283 0xb35d08 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:19595 0xb4b4dc tsubst_template_args(tree_node*, tree_node*, int, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13580 0xb54d8f tsubst_aggr_type /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13796 0xb54d8f tsubst_aggr_type /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13753 0xb49154 tsubst(tree_node*, tree_node*, int, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:16282 0xb35497 gen_elem_of_pack_expansion_instantiation /home/mscastanho/dev/gcc/gcc/cp/pt.cc:12749 0xb35497 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13417 0xb4b6e2 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13566 0xb4b905 tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13517 0xb4b6b4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) /home/mscastanho/dev/gcc/gcc/cp/pt.cc:13578 0xb54d8f tsubst_aggr_type
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 --- Comment #9 from Matheus Castanho --- That one works. Thanks!
[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868 --- Comment #6 from Matheus Castanho --- I can still reproduce the issue after applying the patch in previous comment.
[Bug lto/104868] New: powerpc: Compiling libgfortran with -flto failing with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Bug ID: 104868
Summary: powerpc: Compiling libgfortran with -flto failing with
GCC 12
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: msc at linux dot ibm.com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling libgfortran with -flto (see patch [1]) on ppc64le used to work for a
good while until GCC commit r12-7501-g1301d7f647c7ac . Now it fails with:
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c:
In function 'mmaxloc0_16_i1':
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c:362:1:
error: insn does not satisfy its constraints:
362 | }
| ^
(insn 4106 126 4107 236 (set (reg:V2DI 65 1)
(vec_duplicate:V2DI (reg:DI 0 0 [1496])))
"/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c":315:36
1477 {vsx_splat_v2di_reg}
(expr_list:REG_DEAD (reg:DI 0 0 [1496])
(nil)))
during RTL pass: cprop_hardreg
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c:362:1:
internal compiler error: in extract_constrain_insn, at recog.cc:2670
0x7fff8cce171b __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fff8cce18f7 generic_start_main
../csu/libc-start.c:392
0x7fff8cce18f7 __libc_start_main_impl
../sysdeps/unix/sysv/linux/powerpc/libc-start.c:98
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error:
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/builds/gcc_power10.tuned/./gcc/xgcc
returned 1 exit status
compilation terminated.
/home/tcbot/bot-worker/at_opt/at-next-16.0-0-alpha/powerpc64le-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Steps to reproduce on a Power10:
cd gcc
wget
https://raw.githubusercontent.com/powertechpreview/powertechpreview/0be24b142a81e44ac4abadb3fde4eb0010b79f70/GCC%20PowerPC%20Backport/9/gcc-9-lto.patch
patch -p1 < gcc-9-lto.patch
cd build/gcc
CFLAGS=-O2 CXXFLAGS=-O2 CFLAGS_FOR_TARGET=-O3 CXXFLAGS_FOR_TARGET=-O3
~/src/gcc/configure --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --cache-file=configparms
--prefix=/home/mscastanho/usr --with-long-double-128 --enable-secureplt
--disable-multilib --enable-threads=posix --enable-languages=c,c++,fortran,go
--enable-__cxa_atexit --enable-shared --enable-checking=release
--enable-gnu-indirect-function --enable-lto --enable-linker-build-id
--disable-bootstrap --without-ppl --without-cloog --without-libelf
--with-system-zlib --with-cpu=power10 --with-tune=power10 && make -j60 &>
_make; echo $?
[1]
https://raw.githubusercontent.com/powertechpreview/powertechpreview/0be24b142a81e44ac4abadb3fde4eb0010b79f70/GCC%20PowerPC%20Backport/9/gcc-9-lto.patch
[Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #4 from Matheus Castanho --- Just for completeness, setting the rpath showed the same results: ~/build/gcc> /home/mscastanho/usr/bin/g++ -g -Wl,-rpath,$HOME/usr/lib64 ~/test-ieee128.cpp -o test-shared ~/build/gcc> ./test-shared 6.95329e-310 The output with LD_DEBUG=libs is very much the same as in my previous comment.
[Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #3 from Matheus Castanho --- Using objdump -dr ~/usr/lib64/libstdc++.so.6: [...] 000c9340 <_ZSt16__convert_from_vRKP15__locale_structPciPKcz>: c9340: 25 00 4c 3c addis r2,r12,37 c9344: c0 c5 42 38 addir2,r2,-14912 c9348: a6 02 08 7c mflrr0 c934c: e8 ff a1 fb std r29,-24(r1) c9350: f0 ff c1 fb std r30,-16(r1) c9354: 78 33 dd 7c mr r29,r6 c9358: f8 ff e1 fb std r31,-8(r1) c935c: 78 2b be 7c mr r30,r5 c9360: 78 23 9f 7c mr r31,r4 c9364: 10 00 01 f8 std r0,16(r1) c9368: c1 ff 21 f8 stdur1,-64(r1) c936c: 80 00 e1 f8 std r7,128(r1) c9370: 88 00 01 f9 std r8,136(r1) c9374: 98 00 41 f9 std r10,152(r1) c9378: 90 00 21 f9 std r9,144(r1) c937c: 00 00 63 e8 ld r3,0(r3) c9380: e1 07 ff 4b bl b9b60 <06bf.plt_call.__uselocale@@GLIBC_2.17> c9384: 18 00 41 e8 ld r2,24(r1) c9388: 78 eb a5 7f mr r5,r29 c938c: 78 f3 c4 7f mr r4,r30 c9390: 80 00 c1 38 addir6,r1,128 c9394: 78 1b 69 7c mr r9,r3 c9398: 78 fb e3 7f mr r3,r31 c939c: 78 4b 3e 7d mr r30,r9 c93a0: 01 7f ff 4b bl c12a0 <06bf.plt_call.vsnprintf@@GLIBC_2.17> c93a4: 18 00 41 e8 ld r2,24(r1) c93a8: 78 1b 7f 7c mr r31,r3 c93ac: 78 f3 c3 7f mr r3,r30 c93b0: b1 07 ff 4b bl b9b60 <06bf.plt_call.__uselocale@@GLIBC_2.17> c93b4: 18 00 41 e8 ld r2,24(r1) c93b8: 40 00 21 38 addir1,r1,64 c93bc: 78 fb e3 7f mr r3,r31 c93c0: 10 00 01 e8 ld r0,16(r1) c93c4: e8 ff a1 eb ld r29,-24(r1) c93c8: f0 ff c1 eb ld r30,-16(r1) c93cc: f8 ff e1 eb ld r31,-8(r1) c93d0: a6 03 08 7c mtlrr0 c93d4: 20 00 80 4e blr c93d8: 00 00 00 00 .long 0x0 c93dc: 00 09 00 01 .long 0x1000900 c93e0: 80 03 00 00 .long 0x380 c93e4: 00 00 00 60 nop c93e8: 00 00 00 60 nop c93ec: 00 00 00 60 nop [...] Using LD_LIBRARY_PATH instead of LD_PRELOAD shows the same behavior: ~/build/gcc> LD_LIBRARY_PATH=~/usr/lib64/ ./test-shared 6.95326e-310 Adding LD_DEBUG=libs shows that it is indeed using the libstdc++ I built: ~/build/gcc> LD_LIBRARY_PATH=~/usr/lib64/ LD_DEBUG=libs ./test-shared 38216: find library=libstdc++.so.6 [0]; searching 38216: search path=/home/mscastanho/usr/lib64/glibc-hwcaps/power9:/home/mscastanho/usr/lib64/tls/power9/altivec/dfp:/home/mscastanho/usr/lib64/tls/power9/altivec:/home/ mscastanho/usr/lib64/tls/power9/dfp:/home/mscastanho/usr/lib64/tls/power9:/home/mscastanho/usr/lib64/tls/altivec/dfp:/home/mscastanho/usr/lib64/tls/altivec:/home/mscastanho/usr/l ib64/tls/dfp:/home/mscastanho/usr/lib64/tls:/home/mscastanho/usr/lib64/power9/altivec/dfp:/home/mscastanho/usr/lib64/power9/altivec:/home/mscastanho/usr/lib64/power9/dfp:/home/ms castanho/usr/lib64/power9:/home/mscastanho/usr/lib64/altivec/dfp:/home/mscastanho/usr/lib64/altivec:/home/mscastanho/usr/lib64/dfp:/home/mscastanho/usr/lib64 (LD_LIB RARY_PATH) 38216: trying file=/home/mscastanho/usr/lib64/glibc-hwcaps/power9/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/power9/altivec/dfp/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/power9/altivec/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/power9/dfp/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/power9/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/altivec/dfp/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/altivec/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/dfp/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/tls/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/power9/altivec/dfp/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/power9/altivec/libstdc++.so.6 38216: trying file=/home/mscastanho/usr/lib64/power9/dfp/libstdc++.so.6
[Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Bug ID: 100912
Summary: powerpc64le: ieee128 long double incorrectly printed
when using shared libstdc++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msc at linux dot ibm.com
Target Milestone: ---
Steps to reproduce:
- Build gcc with IEEE128 as the default long double format (using GCC source
revision cb6e6d5faa3f817435b6f203226fa5969d7a7264).
~/build/gcc> ~/src/gcc/configure --prefix=/home/mscastanho/usr
--with-long-double-128 --with-long-double-format=ieee
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --enable-languages=c++ --with-glibc-version=2.33
--disable-bootstrap CC=gcc-11 CXX=g++-11
~/build/gcc> make && make install
~/build/gcc> /home/mscastanho/usr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/mscastanho/usr/bin/g++
COLLECT_LTO_WRAPPER=/home/mscastanho/usr/libexec/gcc/powerpc64le-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: /home/mscastanho/src/gcc/configure
--prefix=/home/mscastanho/usr --with-long-double-128
--with-long-double-format=ieee --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
--enable-languages=c++ --with-glibc-version=2.33 --disable-bootstrap CC=gcc-11
CXX=g++-11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210604 (experimental) (GCC)
- Build and run simple test program with the new compiler and libstdc++
~/build/gcc> cat ~/test-ieee128.cpp
#include
using namespace std;
int main () {
long double n = 1.0L;
cout << n << endl;
return 0;
}
~/build/gcc> /home/mscastanho/usr/bin/g++ -g ~/test-ieee128.cpp -o test-shared
~/build/gcc> LD_PRELOAD=~/usr/lib64/libstdc++.so.6 ./test-shared
6.95326e-310
Here I'd expect "1" to be printed.
If the same program is statically linked to libstdc++, it works as expected:
mscastanho@yanny4:~/build/gcc> /home/mscastanho/usr/bin/g++ -g
-static-libstdc++ ~/test-ieee128.cpp -o test-static
mscastanho@yanny4:~/build/gcc> ./test-static
1
After running the two programs side-by-side under gdb, I found out they are
actually calling two different symbols for vsnprintf on std::__convert_from_v.
Dynamically linked binary:
>>> disas _ZSt16__convert_from_vRKP15__locale_structPciPKcz
Dump of assembler code for function
_ZSt16__convert_from_vRKP15__locale_structPciPKcz:
0x77d19340 <+0>: addis r2,r12,37
0x77d19344 <+4>: addir2,r2,-14912
=> 0x77d19348 <+8>: mflrr0
0x77d1934c <+12>:std r29,-24(r1)
0x77d19350 <+16>:std r30,-16(r1)
0x77d19354 <+20>:mr r29,r6
0x77d19358 <+24>:std r31,-8(r1)
0x77d1935c <+28>:mr r30,r5
0x77d19360 <+32>:mr r31,r4
0x77d19364 <+36>:std r0,16(r1)
0x77d19368 <+40>:stdur1,-64(r1)
0x77d1936c <+44>:std r7,128(r1)
0x77d19370 <+48>:std r8,136(r1)
0x77d19374 <+52>:std r10,152(r1)
0x77d19378 <+56>:std r9,144(r1)
0x77d1937c <+60>:ld r3,0(r3)
0x77d19380 <+64>:bl 0x77d09b60
<06bf.plt_call.__uselocale@@GLIBC_2.17>
0x77d19384 <+68>:ld r2,24(r1)
0x77d19388 <+72>:mr r5,r29
0x77d1938c <+76>:mr r4,r30
0x77d19390 <+80>:addir6,r1,128
0x77d19394 <+84>:mr r9,r3
0x77d19398 <+88>:mr r3,r31
0x77d1939c <+92>:mr r30,r9
0x77d193a0 <+96>:bl 0x77d112a0
<06bf.plt_call.vsnprintf@@GLIBC_2.17><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
0x77d193a4 <+100>: ld r2,24(r1)
0x77d193a8 <+104>: mr r31,r3
0x77d193ac <+108>: mr r3,r30
0x77d193b0 <+112>: bl 0x77d09b60
<06bf.plt_call.__uselocale@@GLIBC_2.17>
0x77d193b4 <+116>: ld r2,24(r1)
0x77d193b8 <+120>: addir1,r1,64
0x77d193bc <+124>: mr r3,r31
0x77d193c0 <+128>: ld r0,16(r1)
0x77d193c4 <+132>: ld r29,-24(r1)
0x77d193c8 <+136>: ld r30,-16(r1)
0x77d193cc &
[Bug c/97709] New: powerpc: ICE when building glibc with latest gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97709 Bug ID: 97709 Summary: powerpc: ICE when building glibc with latest gcc Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msc at linux dot ibm.com Target Milestone: --- Created attachment 49499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49499&action=edit Pre-processed source with the issue This was first observed when upgrading GCC on Advance Toolchain, but I was also able to reproduce this with upstream GCC (commit 93e79ed391b9c636f0). Trying to build glibc with latest GCC causes an internal compiler error: vfprintf-internal.c: In function ‘__vfprintf_internal’: vfprintf-internal.c:1320:1: error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set for SSA_NAME: _1972 in statement: prec_413(ab) = PHI <_1972(36)> PHI argument _1972 for PHI node prec_413(ab) = PHI <_1972(36)> during GIMPLE pass: slp vfprintf-internal.c:1320:1: internal compiler error: verify_ssa failed 0x10dfa0d3 verify_ssa(bool, bool) /home/mscastanho/src/gcc/gcc/tree-ssa.c:1208 0x1099fc1f execute_function_todo /home/mscastanho/src/gcc/gcc/passes.c:2046 0x109a088b do_per_function /home/mscastanho/src/gcc/gcc/passes.c:1687 0x109a0aaf execute_todo /home/mscastanho/src/gcc/gcc/passes.c:2093 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Preprocessed source generated with -save-temps is attached to the bug. The issue only happens if I use -mcpu=power9 or -mcpu=power10. -mcpu=power8 seems to be OK. Cmdline used: ~/usr/bin/gcc -m64 ./stdio-common/vfprintf-internal.i -c -std=gnu11 -fgnu89-inline -g -O3 -mcpu=power9 -Wall NOTE: The original Advance Toolchain build used a slightly older GCC (commit 943cc2a1b70f), and the error message I saw was a bit different (although still somewhat related): Unable to coalesce ssa_names 219 and 1972 which are marked as MUST COALESCE. prec_219(ab) and _1972 during RTL pass: expand vfprintf-internal.c: In function ‘__vfprintf_internal’: vfprintf-internal.c:148:25: internal compiler error: SSA corruption 148 | # define vfprintf __vfprintf_internal | ^~~ vfprintf-internal.c:1320:1: note: in expansion of macro ‘vfprintf’ 1320 | vfprintf (FILE *s, const CHAR_T *format, va_list ap, unsigned int mode_flags) | ^~~~ 0x109e7dc7 fail_abnormal_edge_coalesce /home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-ssa-coalesce.c:1003 0x109e7dc7 coalesce_partitions /home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-ssa-coalesce.c:1425 0x109e7dc7 coalesce_ssa_name(_var_map*) /home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-ssa-coalesce.c:1755 0x1097f8bb remove_ssa_form /home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-outof-ssa.c:1065 0x1097f8bb rewrite_out_of_ssa(ssaexpand*) /home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-outof-ssa.c:1323 0x1035f04b execute /home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/cfgexpand.c:6378
[Bug tree-optimization/92955] [10 regression] gcc.dg/vect/pr60505.c fails starting with r279392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955 --- Comment #6 from Matheus Castanho --- Hi. Any updates on this issue?
[Bug testsuite/92955] [10 regression] gcc.dg/vect/pr60505.c fails starting with r279392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
Matheus Castanho changed:
What|Removed |Added
CC||msc at linux dot ibm.com
--- Comment #3 from Matheus Castanho ---
A very similar issue is affecting glibc builds with GCC 10 on powerpc64le. But
it's only failing with -O3 (-O2 is fine). Here's another reproducer in case it
helps (derived from code from iconv):
$ cat overflow-reproducer.c
#include
typedef struct state {
int count;
char bytes[4];
} state_t;
void foo (
state_t *state,
const unsigned char **inptrp,
const unsigned char *inend)
{
const unsigned char *inptr = *inptrp;
size_t inlen;
for (inlen = 0; inlen < (size_t) (state->count & 7); ++inlen)
/* do something */;
if (inptr + (4 - inlen) > inend)
{
while (inptr < inend)
state->bytes[inlen++] = *inptr++;
}
}
$ gcc -O3 -Wall -c overflow-reproducer.c
overflow-reproducer.c: In function ‘foo’:
overflow-reproducer.c:22:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
22 | state->bytes[inlen++] = *inptr++;
| ~~^~
overflow-reproducer.c:5:10: note: at offset [4, 11] to object ‘bytes’ with size
4 declared here
5 | char bytes[4];
| ^
