[Bug c++/94185] New: gcc-10 crashes with "error: unable to generate reloads for {*zero_extendsidi2} internal compiler error: in curr_insn_transform, at lra-constraints.c:4006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
Bug ID: 94185
Summary: gcc-10 crashes with "error: unable to generate reloads
for {*zero_extendsidi2} internal compiler error: in
curr_insn_transform, at lra-constraints.c:4006
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 48037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48037&action=edit
bug.cc
Originally observed on smartmontools-7.0, reduced with creduce down to:
struct a {
int b;
int c();
a() : b(c()) {}
~a();
char *e();
};
struct f {
void g(int);
};
struct ar {
int au[256];
f h(int);
} bb;
a i();
a j(int);
long k(int, ar);
int d;
void l(char *, ar m, long n) {
switch (m.au[d])
case 0:
n &= 4294967295;
bb.h(0).g(n);
}
void o() {
ar bd;
a bh, bi, attrname = j(0) = i();
int be = k(0, bd);
l(attrname.e(), bd, be);
}
Exact command to crash gcc-master:
$ ./xg++ -B. -O2 -c -o /tmp/bug.o /tmp/bug.cc -fstack-protector-strong -fPIE
/tmp/bug.cc: In function 'void o()':
/tmp/bug.cc:30:1: error: unable to generate reloads for:
30 | }
| ^
(insn 62 61 63 8 (set (mem/c:DI (plus:DI (reg/f:DI 19 frame)
(const_int -2152 [0xf798])) [7 %sfp+-2104 S8 A64])
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -2152 [0xf798])) [7 %sfp+-2104 S4
A64]))) "/tmp/bug.cc":22:7 114 {*zero_extendsidi2}
(nil))
during RTL pass: reload
/tmp/bug.cc:30:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4006
0x7fc532a94dd9 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler is built as:
$ ./xg++ -B. -v
Reading specs from ./specs
COLLECT_GCC=./xg++
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200315 (experimental) (GCC)
[Bug target/94185] [10 Regression] crashes with "error: unable to generate reloads for {*zero_extendsidi2} internal compiler error: in curr_insn_transform, at lra-constraints.c:4006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185 --- Comment #9 from Sergei Trofimovich --- Now smartmontools-7.0 builds successfully against gcc version 10.0.1 20200317 (experimental), commit 2e30d3e3e88b6a544074ff89de4974bc5e200e89. Thank you for a superfast fix!
[Bug lto/94259] New: --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 Bug ID: 94259 Summary: --without-zstd seems to have no effect and links libzstd if available Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru CC: marxin at gcc dot gnu.org Target Milestone: --- Built gcc with --without-zstd as: $ ../gcc/configure --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS=-O1 CXXFLAGS=-O1 --with-sysroot=/usr/x86_64-HEAD-linux-gnu --without-zstd But cc1plus still links to libzstd: ldd ./gcc/cc1plus linux-vdso.so.1 (0x7ffed53f) libmpc.so.3 => /usr/lib64/libmpc.so.3 (0x7ff32f12a000) libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x7ff32f0a9000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x7ff32f02f000) libdl.so.2 => /lib64/libdl.so.2 (0x7ff32f029000) libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x7ff32ef95000) libm.so.6 => /lib64/libm.so.6 (0x7ff32ee52000) libc.so.6 => /lib64/libc.so.6 (0x7ff32ec7e000) /lib64/ld-linux-x86-64.so.2 (0x7ff32f1d4000) Loks like it happens because library/header detection happens regardless of user's setting in gcc/configure.ac: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=0d6230e0ca1bdd1f7de34ad452efac867351121a;hb=HEAD#l1316 1323 AC_ARG_WITH(zstd, 1324 [AS_HELP_STRING([--with-zstd=PATH], 1325 [specify prefix directory for installed zstd library. 1326 Equivalent to --with-zstd-include=PATH/include 1327 plus --with-zstd-lib=PATH/lib])]) ... 1374 # LTO can use zstd compression algorithm 1375 save_LIBS="$LIBS" 1376 LIBS= 1377 AC_SEARCH_LIBS(ZSTD_compress, zstd) 1378 ZSTD_LIB="$LIBS" 1379 LIBS="$save_LIBS" 1380 AC_SUBST(ZSTD_LIB) It looks like headers/library detection happens regardless of --with-zstd/--without-zstd flag being passed. I have zstd installed in /usr and it always get picked up.
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 --- Comment #1 from Sergei Trofimovich --- I also noticed a minor infelicity: if you pass just --with-zstd build system will do a few unexpected things: - it will not fail of zstd is not present in system but will silently skip zstd support - it will use 'yes/include' and 'yes/lib' as paths to zstd. I think it's never an expected location. 1334 case "x$with_zstd" in 1335 x) ;; 1336 xno) 1337 ZSTD_INCLUDE=no 1338 ZSTD_LIB=no 1339 ;; 1340 *) ZSTD_INCLUDE=$with_zstd/include 1341 ZSTD_LIB=$with_zstd/lib 1342 ;; 1343 esac
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 --- Comment #4 from Sergei Trofimovich --- (In reply to Martin Liška from comment #3) > Created attachment 48093 [details] > Patch candidate > > There's a patch candidate. Can you please test it? The following seems to inject 'no' library: $ ../gcc/configure --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS=-O1 CXXFLAGS=-O1 --with-sysroot=/usr/x86_64-HEAD-linux-gnu --without-zstd Build fails as: g++ -no-pie -O1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.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 i386-c.o glibc-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -L./../zlib -lz no g++: error: no: No such file or directory Probably due to: $ fgrep -i zstd gcc/config.log ZSTD_INCLUDE='no' ZSTD_LIB='no' I guess these should be empty instead of 'yes' / 'no'.
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #3 from Sergei Trofimovich --- Asked gcc mailing list what interaction we do expect with configure options --disable-multilib/--with-multilib-list= and out put of 'gcc -print-multi-os-directory' as: https://gcc.gnu.org/pipermail/gcc/2020-March/231981.html
[Bug translation/90528] ICE caused b bad format string in gimple-ssa-warn-restrict.c:1803 for 'es' locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90528 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Sergei Trofimovich --- Was fixed for gcc-9.2.0: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a750cf5f4fe06781fee6c409591753b75ca98191
[Bug driver/94491] New: -g2 debugging level is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94491 Bug ID: 94491 Summary: -g2 debugging level is not documented Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- A tiny backstory: to profile a program I built it with '-g'. The result did not fit in my RAM and machine crashed. Looking at the doc I found out '-g' means '-g2' (and not '-g1'). Worth documenting what -g2 actually do? Others are interested as well: https://stackoverflow.com/questions/10475040/gcc-g-vs-g3-gdb-flag-what-is-the-difference 'man gcc' covers only 0,1 and 3: """ -glevel -ggdblevel -gstabslevel -gxcofflevel -gvmslevel Request debugging information and also use level to specify how much information. The default level is 2. Level 0 produces no debug information at all. Thus, -g0 negates -g. Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables. Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3. If you use multiple -g options, with or without level numbers, the last such option is the one that is effective. -gdwarf does not accept a concatenated debug level, to avoid confusion with -gdwarf-level. Instead use an additional -glevel option to change the debug level for DWARF. """
[Bug preprocessor/94657] New: [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 Bug ID: 94657 Summary: [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Created attachment 48305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48305&action=edit libcpp-ar.patch Initially reported by Agostino Sarubbo as https://bugs.gentoo.org/718004. There Gentoo builds gcc-9.3.0 as: --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu and observes 'ar' being called by libcpp. It should be 'x86_64-pc-linux-gnu-ar' instead. libcpp/Makefile.in hardcodes 'AR = ar' (but does not hardcode RANLIB for example: 'RANLIB = @RANLIB@'). A few other tools do it: $ git grep 'AR = ar' | cat gcc/ada/gcc-interface/Makefile.in:AR = ar intl/Makefile.in:AR = ar libcpp/Makefile.in:AR = ar libdecnumber/Makefile.in:AR = ar but only libcpp refers 'ar' and fails build when 'ar' does not exist: ar cru libcpp.a charset.o directives.o directives-only.o errors.o expr.o files.o identifiers.o init.o lex.o line-map.o macro.o mkdeps.o pch.o symtab.o traditional.o /bin/bash: ar: command not found Attached patch adds AR detection similar to other libraries. But maybe it should be set in top-level Makefile?
[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 --- Comment #2 from Sergei Trofimovich --- Sent as https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544379.html
[Bug tree-optimization/95118] New: gcc-10 and master -O3 -fopt-info-vec causes gcc to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
Bug ID: 95118
Summary: gcc-10 and master -O3 -fopt-info-vec causes gcc to
hang
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The bug originally reported by Adrien Dessemond as
https://bugs.gentoo.org/722774 where gzip-1.10's ./configure CFLAGS="-O3 -pipe
-march=native -fomit-frame-pointer -fopt-info-vec -mindirect-branch=thunk
-mindirect-branch-register" makes gcc hang.
Minimal reproducer against gcc-10.1.0 anf gcc-master is:
// $ cat bug.c
void a();
void b() {
union {
int c[4];
long double d;
} e = {{0, 0, 4}};
a(e.d);
}
$ /usr/bin/x86_64-pc-linux-gnu-gcc-10.1.0 -o conftest -O3 -fopt-info-vec -c
bug.c
Reproducible on the following gcc config against master:
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200513 (experimental) (GCC)
[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118 --- Comment #1 from Sergei Trofimovich --- Created attachment 48528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48528&action=edit bug.c
[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118 --- Comment #2 from Sergei Trofimovich --- Seems to be a regression since gcc-9.3.0.
[Bug tree-optimization/95118] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118 Sergei Trofimovich changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Sergei Trofimovich --- Bisect points to an old revision. Might be a coincidence? 38988cbf9ebaa96fb1e891a46aa063f0c298a2e2 is the first bad commit commit 38988cbf9ebaa96fb1e891a46aa063f0c298a2e2 Author: Richard Biener Date: Mon Jul 8 07:09:24 2019 + re PR tree-optimization/83518 (Missing optimization: useless instructions should be dropped) 2019-07-08 Richard Biener PR tree-optimization/83518 * tree-ssa-sccvn.c: Include splay-tree.h. (struct pd_range, struct pd_data): New. (struct vn_walk_cb_data): Add data to track partial definitions. (vn_walk_cb_data::~vn_walk_cb_data): New. (vn_walk_cb_data::push_partial_def): New. (pd_tree_alloc, pd_tree_dealloc, pd_range_compare): New. (vn_reference_lookup_2): When partial defs are registered give up. (vn_reference_lookup_3): Track partial defs for memset and constructor zeroing and for defs from constants. * gcc.dg/tree-ssa/ssa-fre-73.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-74.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-75.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-76.c: Likewise. * g++.dg/tree-ssa/pr83518.C: Likewise. From-SVN: r273194 gcc/ChangeLog | 13 + gcc/testsuite/ChangeLog| 9 + gcc/testsuite/g++.dg/tree-ssa/pr83518.C| 27 ++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-73.c | 14 ++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-74.c | 16 ++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-75.c | 34 +++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-76.c | 16 ++ gcc/tree-ssa-sccvn.c | 389 + 8 files changed, 469 insertions(+), 49 deletions(-) create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr83518.C create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-73.c create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-74.c create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-75.c create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-76.c
[Bug lto/95194] New: bootstrap-lto fails on musl (bundled libintl uses asm aliases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194
Bug ID: 95194
Summary: bootstrap-lto fails on musl (bundled libintl uses asm
aliases)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
The bug is originally reported by Andrew Savchenko as
https://bugs.gentoo.org/723370. There gcc's bootstrap-lto fails on musl libc.
It's slightly different from glibc as libintl relies on glibc-specific gettext
symbols like '_nl_msg_cat_cntr'.
The bug:
$ /var/tmp/portage/sys-devel/gcc-10.1.0/work/gcc-10.1.0/configure
--host=x86_64-gentoo-linux-musl --build=x86_64-gentoo-linux-musl --prefix=/usr
--bindir=/usr/x86_64-gentoo-linux-musl/gcc-bin/10.1.0
--includedir=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0/include
--datadir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0
--mandir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/man
--infodir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion=Gentoo Hardened 10.1.0 p1 --enable-esp
--enable-libstdcxx-time --with-build-config=bootstrap-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --with-multilib-list=m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--disable-vtable-verify --disable-libvtv --without-zstd --disable-libquadmath
--enable-lto --without-isl --disable-libsanitizer --enable-default-pie
--enable-default-ssp
$ make -j8 -l10 'LDFLAGS=-march=native -pipe
-Wl,-O1,--as-needed,--sort-common,-z,combreloc,-z,relro,-z,now,--relax,--hash-style=gnu'
STAGE1_CFLAGS= LIBPATH=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0
'BOOT_CFLAGS=-m64 -march=native -pipe -O2' bootstrap-lean
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/./prev-gcc/xg++
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/./prev-gcc/
-B/usr/x86_64-gentoo-linux-musl/bin/ -nostdinc++
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/src/.libs
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/libsupc++/.libs
-isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/include/x86_64-gentoo-linux-musl
-isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/include
-isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/gcc-10.1.0/libstdc++-v3/libsupc++
-L/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/src/.libs
-L/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/libsupc++/.libs
-DEXTRA_OPTIONS -m64 -march=native -pipe -O2 -fno-checking -flto=jobserver
-frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE
-static-libstdc++ -static-libgcc -no-pie -o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o build/sort.o .././libiberty/libiberty.a
./../intl/libintl.a
...
/usr/x86_64-gentoo-linux-musl/bin/ld:
/var/tmp/portage/sys-devel/gcc-10.1.0/temp/genmatch.NlicMk.ltrans2.ltrans.o: in
function `main':
:(.text.startup+0x94ba): undefined reference to `libintl_dgettext'
/usr/x86_64-gentoo-linux-musl/bin/ld:
/var/tmp/portage/sys-devel/gcc-10.1.0/temp/genmatch.NlicMk.ltrans3.ltrans.o: in
function `cpp_diagnostic(cpp_reader*, cpp_diagnostic_level, cpp_warning_reason,
char const*, __va_list_tag (*) [1])':
:(.text+0x2732): undefined reference to `libintl_dgettext'
...
Mechanically it fails because 'libintl_dgettext' is decclared as an asm alias:
"""
extern char *dgettext (const char *__domainname, const char *__msgid)
__asm__ ("" "libintl_dgettext")
__attribute__ ((__format_arg__ (2)));
$ ../prev-gcc/lto-dump -list errors.o | fgrep dgettext
function default 0 *libintl_dgettext
$ ../prev-gcc/lto-dump -demangle -list errors.
[Bug lto/95194] bootstrap-lto fails on musl (bundled libintl uses asm aliases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194 --- Comment #1 from Sergei Trofimovich --- https://gcc.gnu.org/PR48200 touches on why asm aliases are problematic.
[Bug lto/95224] New: -flto -save-temps uses very unusual name for resolution file, looks arbitrary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95224
Bug ID: 95224
Summary: -flto -save-temps uses very unusual name for
resolution file, looks arbitrary
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org,
rguenth at gcc dot gnu.org
Target Milestone: ---
Encountered when was debugging lto/95194.
Reproducer:
# good
$ rm -- *; echo 'int main(){}' | gcc -c -x c -flto - -o main.o; gcc main.o -o
main -flto -save-temps; ls -- *.res
main.res
# unexpected
$ rm -- *; echo 'int main(){}' | gcc -c -x c -flto - -o main.o; gcc main.o -o
main -flto -save-temps -lm; ls -- *.res
-lm.res
Expected behaviour: always get 'main.res' resolution file.
In real scenario I was building 'genmatch' and got '-lm.res'. It confused me
quite a bit: I explored very strange possibilities: driver did not recognize
-lm as a library, '-lm.res' is not the only response file out there, etc.
Would it be reasonable for response file to always use the same basename as
'-o' paramemter?
[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Sergei Trofimovich --- On #gcc Tobias pointed out that similar patch was merged a few days ago: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=731c4ce0e93065fb70db5faa2bd6c9c6bad56738 https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546337.html
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 --- Comment #6 from Sergei Trofimovich --- Gentoo runs the patch for a while system-wide and it seems to work fine. Worth submitting the patch for review?
[Bug c++/95528] New: internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528
Bug ID: 95528
Summary: internal compiler error: in emit_move_insn, at
expr.c:3814
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The bug is initially reported in https://bugs.gentoo.org/727028 as an ICE on
firefox-77 code by Thomas Deutschmann.
Here is the minimal reproducer reduced by creduce:
$ cat bug.cc
template struct b {
typedef a c __attribute__((vector_size(sizeof(a) * 4)));
union {
c d;
struct {
a e, f, g, h;
};
};
b();
b(const b &i) : d(i.d) {}
static b j(c);
template operator b() {
b::j(typename b::c{e, f, g, h});
}
};
template using l = b;
using m = l;
using n = l;
m o(n i) { return i; }
b q;
void p() { o(q); }
$ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++ -march=skylake-avx512 -O2 -c bug.cc
-o bug.o
during RTL pass: expand
bug.cc: In function 'void p()':
bug.cc:13:12: internal compiler error: in emit_move_insn, at expr.c:3814
13 | b::j(typename b::c{e, f, g, h});
| ~~~^~
0x5cb5cc emit_move_insn(rtx_def*, rtx_def*)
../../gcc-11.0.0_pre/gcc/expr.c:3814
0x82e459 load_register_parameters
../../gcc-11.0.0_pre/gcc/calls.c:3143
0x82e459 expand_call(tree_node*, rtx_def*, int)
../../gcc-11.0.0_pre/gcc/calls.c:4589
0x942856 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-11.0.0_pre/gcc/expr.c:11135
0x94cc64 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-11.0.0_pre/gcc/expr.c:8358
0x94cc64 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc-11.0.0_pre/gcc/expr.c:5752
0x94e1f9 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-11.0.0_pre/gcc/expr.c:5514
0x83c40a expand_call_stmt
../../gcc-11.0.0_pre/gcc/cfgexpand.c:2701
0x83c40a expand_gimple_stmt_1
../../gcc-11.0.0_pre/gcc/cfgexpand.c:3682
0x83c40a expand_gimple_stmt
../../gcc-11.0.0_pre/gcc/cfgexpand.c:3847
0x842916 expand_gimple_basic_block
../../gcc-11.0.0_pre/gcc/cfgexpand.c:5887
0x842916 execute
../../gcc-11.0.0_pre/gcc/cfgexpand.c:6571
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
Both gcc-10 and gcc-master are affected.
gcc-master crash for comparison:
$ ${HOME}/dev/git/gcc-native-quick/gcc/xg++ -B
${HOME}/dev/git/gcc-native-quick/gcc -march=skylake-avx512 -O2 -c bug.cc -o
bug.o
during RTL pass: expand
bug.cc: In function 'void p()':
bug.cc:13:12: internal compiler error: in emit_move_insn, at expr.c:3814
13 | b::j(typename b::c{e, f, g, h});
| ~~~^~
0x7f1550e53d59 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ ${HOME}/dev/git/gcc-native-quick/gcc/xg++ -B
${HOME}/dev/git/gcc-native-quick/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xg++
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200604 (experimental) (GCC)
Not sure if it's the same as bug #95394. That bug says it's a gcc-11
regression, but this one happens on gcc-10.1.0 as well.
[Bug c++/95528] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #1 from Sergei Trofimovich --- It seems to be somehow specific to avx512: This works: $ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++-10.1.0 -march=skylake -O2 -c bug.cc -o bug.o This ICEs: $ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++-10.1.0 -march=skylake-avx512 -O2 -c bug.cc -o bug.o
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #5 from Sergei Trofimovich --- My bisect ended up at: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=78307657cf9675bc4aa2e77561c823834714b4c8 $ git bisect bad 78307657cf9675bc4aa2e77561c823834714b4c8 is the first bad commit commit 78307657cf9675bc4aa2e77561c823834714b4c8 Author: Richard Biener Date: Thu Nov 28 12:22:04 2019 + re PR tree-optimization/92645 (Hand written vector code is 450 times slower when compiled with GCC compared to Clang) 2019-11-28 Richard Biener PR tree-optimization/92645 * tree-ssa-forwprop.c (get_bit_field_ref_def): Also handle conversions inside a mode class. Remove restriction on preserving the element size. (simplify_vector_constructor): Deal with the above and for identity permutes also try using VEC_UNPACK_[FLOAT_]LO_EXPR and VEC_PACK_TRUNC_EXPR. * gcc.target/i386/pr92645-4.c: New testcase. From-SVN: r278806 gcc/ChangeLog | 10 gcc/testsuite/ChangeLog | 5 ++ gcc/testsuite/gcc.target/i386/pr92645-4.c | 56 ++ gcc/tree-ssa-forwprop.c | 96 ++- 4 files changed, 154 insertions(+), 13 deletions(-) create mode 100644 gcc/testsuite/gcc.target/i386/pr92645-4.c
[Bug plugins/95648] New: gcc/configure: line 26509: objdump: command not found: config/gcc-plugin.m4 uses 'objdump' instead of ${host}-objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95648
Bug ID: 95648
Summary: gcc/configure: line 26509: objdump: command not found:
config/gcc-plugin.m4 uses 'objdump' instead of
${host}-objdump
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: pmuldoon at gcc dot gnu.org
Target Milestone: ---
Looks similar to bug #67590.
Gentoo always builds gcc as:
$ ./configure --build=... --host=... --target=...
and assumes tool-prefixed tools to be always used, like ${CHOST}-ld,
${CHOST}-nm. To make sure there are no accidental fallbacks to unprefixed tools
we have an optional mode to remove tools like 'objdump' and leave only
${CHOST}-objdump around.
It almost always work except for gcc plugins where objdump is referred as-is.
Here is the full problematic configure command:
"""
$ /tmp/portage/cross-avr/gcc-10.1.0/work/gcc-10.1.0/configure
--host=x86_64-pc-linux-gnu --target=avr --build=x86_64-pc-linux-gnu
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/avr/gcc-bin/10.1.0
--includedir=/usr/lib/gcc/avr/10.1.0/include
--datadir=/usr/share/gcc-data/avr/10.1.0
--mandir=/usr/share/gcc-data/avr/10.1.0/man
--infodir=/usr/share/gcc-data/avr/10.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/avr/10.1.0/include/g++-v10
--with-python-dir=/share/gcc-data/avr/10.1.0/python --enable-languages=c
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 10.1.0 p1
--disable-esp --enable-poison-system-directories --enable-shared
--disable-threads --disable-bootstrap --enable-multilib --disable-fixed-point
--disable-libgomp --disable-libmudflap --disable-libssp --disable-libada
--disable-systemtap --disable-vtable-verify --disable-libvtv --without-zstd
--disable-libquadmath --enable-lto --without-isl --disable-libsanitizer
--disable-default-pie --enable-default-ssp
$ make
...
checking dl_iterate_phdr in target C library... unknown
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether to avoid linking multiple front-ends at once... no
Links are now set up to build a cross-compiler
from x86_64-pc-linux-gnu to avr-unknown-none.
checking for exported symbols...
/tmp/portage/cross-avr/gcc-10.1.0/work/gcc-10.1.0/gcc/configure: line 26509:
objdump: command not found
yes
checking for -rdynamic...
/tmp/portage/cross-avr/gcc-10.1.0/work/gcc-10.1.0/gcc/configure: line 26519:
objdump: command not found
no
...
"""
Note: objdump is referred here from config/gcc-plugin.m4:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=config/gcc-plugin.m4;h=8f278719118277230f493e0185fb2a09593e9e45;hb=HEAD#l46
"""
47if test x$build = x$host; then
48 export_sym_check="objdump${exeext} -T"
49elif test x$host = x$target; then
50 export_sym_check="$gcc_cv_objdump -T"
51else
52 export_sym_check=
53fi
"""
AFAIU here 'export_sym_check="objdump${exeext} -T"' is triggered.
Should it use an $ac_cv_prog_OBJDUMP value instead?
[Bug plugins/95648] gcc/configure: line 26509: objdump: command not found: config/gcc-plugin.m4 uses 'objdump' instead of ${host}-objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95648
--- Comment #1 from Sergei Trofimovich ---
The following seems to be enough to use detected objdump:
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -45,7 +45,7 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
;;
*)
if test x$build = x$host; then
-export_sym_check="objdump${exeext} -T"
+export_sym_check="$ac_cv_prog_OBJDUMP -T"
elif test x$host = x$target; then
export_sym_check="$gcc_cv_objdump -T"
else
[Bug c++/95768] New: -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95768
Bug ID: 95768
Summary: -march=sandybridge -O2 -Wall crashes as 'during GIMPLE
pass: uninit ... Segmentation fault'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
SIGSEGV initially observed on qtcore-5.14.2 package.
Here is the minimal(ish) reproducer:
// $ cat bug.cc
extern "C" void *malloc(unsigned long);
class a {
public:
enum c { Array };
};
class d {
public:
static int e(int);
};
class f {
public:
int g;
void operator=(int) { d::e(g); }
};
template < typename, int, int > using h = f;
template < int i, int j > using k = h< int, i, j >;
template < int i, int j > using l = h< int, i, j >;
class m {
public:
k< 0, 1 > is_object;
k< 1, 1 > length;
};
class n {
public:
m *o() { return (m *)this; }
};
class p {
public:
enum {} alloc;
n *header;
p(a::c) {
header = (n *)malloc(alloc);
m b = *header->o();
b.length = 0;
}
};
void detach2() { p(a::Array); }
LANG=C /usr/bin/x86_64-pc-linux-gnu-g++ -march=sandybridge -O2 -Wall -c bug.cc
-o bug.o
bug.cc: In constructor 'p::p(a::c)':
bug.cc:32:26: warning: '*.p::alloc' is used uninitialized
[-Wuninitialized]
32 | header = (n *)malloc(alloc);
| ^
'
during GIMPLE pass: uninit
In function 'void detach2()':
Segmentation fault
37 | void detach2() { p(a::Array); }
| ^~~
0xa9c91f crash_signal
../../gcc-11.0.0_pre/gcc/toplev.c:328
0x7f2dc77d2c3f ???
/usr/src/debug/sys-libs/glibc-2.31-r5/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xce7494 location_wrapper_p(tree_node const*)
../../gcc-11.0.0_pre/gcc/tree.h:3999
0xce7494 tree_strip_any_location_wrapper(tree_node*)
../../gcc-11.0.0_pre/gcc/tree.h:4011
0xce7494 integer_onep(tree_node const*)
../../gcc-11.0.0_pre/gcc/tree.c:2573
0x4e0ee3 dump_expr
../../gcc-11.0.0_pre/gcc/cp/error.c:2386
0x4e3640 expr_to_string(tree_node*)
../../gcc-11.0.0_pre/gcc/cp/error.c:3109
0x4e3cfc cp_printer
../../gcc-11.0.0_pre/gcc/cp/error.c:4264
0x13e0646 pp_format(pretty_printer*, text_info*)
../../gcc-11.0.0_pre/gcc/pretty-print.c:1475
0x13d48e2 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc-11.0.0_pre/gcc/diagnostic.c:1159
0x13d683a diagnostic_impl
../../gcc-11.0.0_pre/gcc/diagnostic.c:1309
0x13d683a warning_at(unsigned int, int, char const*, ...)
../../gcc-11.0.0_pre/gcc/diagnostic.c:1446
0xc5e7ed maybe_warn_operand
../../gcc-11.0.0_pre/gcc/tree-ssa-uninit.c:418
0xc619e9 warn_uninitialized_vars
../../gcc-11.0.0_pre/gcc/tree-ssa-uninit.c:640
0xc66016 execute
../../gcc-11.0.0_pre/gcc/tree-ssa-uninit.c:2936
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
[Bug c++/95768] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95768
--- Comment #1 from Sergei Trofimovich ---
On today's gcc master configured as:
$ ~/dev/git/gcc-native-quick/gcc/xg++
-B/home/slyfox/dev/git/gcc-native-quick/gcc/ -v # -march=sandybridge -O2 -Wall
-c bug.cc -o bug.o -
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xg++
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200619 (experimental) (GCC)
crash is reproducible:
$ ~/dev/git/gcc-native-quick/gcc/xg++
-B/home/slyfox/dev/git/gcc-native-quick/gcc/ -march=sandybridge -O2 -Wall -c
bug.cc -o bug.o
bug.cc: In constructor 'p::p(a::c)':
bug.cc:32:26: warning: '*.p::alloc' is used uninitialized
[-Wuninitialized]
32 | header = (n *)malloc(alloc);
| ^
'
during GIMPLE pass: uninit
In function 'void s()':
Segmentation fault
37 | void s() { p(a::q); }
| ^
0x7f7b2395dc3f ???
/usr/src/debug/sys-libs/glibc-2.31-r5/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f7b23948d49 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug other/95811] New: configure fails when crossing to x86_64: checking for CET support...configure: error: cannot run test program while cross compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95811 Bug ID: 95811 Summary: configure fails when crossing to x86_64: checking for CET support...configure: error: cannot run test program while cross compiling Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru CC: hjl.tools at gmail dot com Target Milestone: --- Initially reported by Aisha Tammy as https://bugs.gentoo.org/729074. There attempt to cross-compile x86_64 to x86_64 with slightly different tollchain prefix (to unshare defaults) fails as: """ $ .../configure --host=x86_64-UNREG-linux-gnu --target=x86_64-UNREG-linux-gnu --build=x86_64-pc-linux-gnu ... checking for CET support... configure: error: in `/tmp/portage-tmpdir/portage/sys-devel/gcc-10.1.0-r1/work/build/libiberty': configure: error: cannot run test program while cross compiling See `config.log' for more details make[1]: *** [Makefile:7996: configure-libiberty] Error 1 """ Passing --disable-cet explicitly allows passing the condition. Should AC_TRY_RUN default to --disable-cet automatically?
[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94998 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #7 from Sergei Trofimovich --- *** Bug 95811 has been marked as a duplicate of this bug. ***
[Bug other/95811] configure fails when crossing to x86_64: checking for CET support...configure: error: cannot run test program while cross compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95811 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Sergei Trofimovich --- Was probably fixed in https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d17cdc17c90ce77cb90c569322c1f241d3530cec which added cross_compiling case. My apologies for the noise. *** This bug has been marked as a duplicate of bug 94998 ***
[Bug target/95912] New: internal compiler error: in execute, at adjust-alignment.c:74 with 'ICE on '-m32 -mpreferred-stack-boundary=2''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95912
Bug ID: 95912
Summary: internal compiler error: in execute, at
adjust-alignment.c:74 with 'ICE on '-m32
-mpreferred-stack-boundary=2''
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Originally ICE happened when I attempted to compile valgrind-3.16.1.
Minimal reproducer is very simple:
$ cat bug.c
a() { long long b; }
$ LANG=C gcc-11.0.0 a.c -c -m32 -mpreferred-stack-boundary=2
bug.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | a() { long long b; }
| ^
during GIMPLE pass: adjust_alignment
bug.c: In function 'a':
bug.c:1:1: internal compiler error: in execute, at adjust-alignment.c:74
0x7f9fcda79d49 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
GCC was configured as:
$ /home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
-B/home/slyfox/dev/git/gcc-native-quick/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200626 (experimental) (GCC)
[Bug c++/82953] ICE in tree_check() ../../gcc/gcc/tree.h:3087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82953 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #3 from Sergei Trofimovich --- Given that gcc-8 works let's close as obsolete.
[Bug c++/86353] g++7 -std=c++17 ICEs as internal compiler error: in gimplify_expr, at gimplify.c:12201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86353 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Sergei Trofimovich --- Let's declare fixed as it works with gcc-8 and above.
[Bug c++/95942] New: [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Bug ID: 95942
Summary: [11 regression] offsetof on an array: error: 'e' is
not a constant expression
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The original error is seen on https://www.dolphin-emu.org/ project as a build
error. Minimized example looks the following:
"""
// $ cat.bug.cc
struct a {
int b;
char c[100];
};
unsigned long d(long e) { return __builtin_offsetof(a, c[e]); }
"""
OK:
$ LANG=C g++-10.1.0 -c bug.cc -o bug.o
OK:
$ LANG=C clang++-10 -c bug.cc -o bug.o
FAIL:
$ LANG=C g++-11.0.0 -c bug.cc -o bug.o
bug.cc: In function 'void d(long int)':
bug.cc:8:42: error: 'e' is not a constant expression
8 | void d(long e) { __builtin_offsetof(a, c[e]); }
|
Who is wrong here? gcc-10 or gcc-11?
[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
--- Comment #1 from Sergei Trofimovich ---
Original code looks is at
https://github.com/dolphin-emu/dolphin/blob/2e8d1dd1dbcca7095e9d842f1df037cbe76868e4/Source/Core/Core/DSP/Jit/x64/DSPEmitter.cpp#L476:
"""
...
Gen::OpArg DSPEmitter::M_SDSP_r_st(size_t index)
{
return MDisp(R15, static_cast(offsetof(SDSP, r.st[index])));
}
...
"""
[Bug target/96015] New: [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Bug ID: 96015
Summary: [regression] gcc-10.1.0 miscompiles Python on hppa
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: dave.anglin at bell dot net, law at redhat dot com
Target Milestone: ---
Target: hppa2.0-unknown-linux-gnu
Originally reported as https://bugs.gentoo.org/729570 where gcc-10.1.0
miscompiles Python into generating invalid bytecode. I shrunk Python's code
into single file that illustrates the problem:
// $ cat bug_test.c
/*
The test is extracted from Python-3.9.0 miscompilation
on hppa2.0: https://bugs.gentoo.org/729570
Original bug happens as an invalid bytecode generation
due to bad results from 'long_richcompare(0x, 1, EQ)' calls.
Failure example:
$ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -O1 bug_test.c -o
good-bug
$ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -O2 bug_test.c -o
bad-bug
$ ./good-bug
long_richcompare(2, 1, EQ) = FALSE (expect FALSE)
$ ./bad-bug
long_richcompare(2, 1, EQ) = TRUE (expect FALSE)
*/
// We use '__attribute__((noipa));' aggressively to simulate
// unavailable function definitions from outside translation units.
static int cmp(int *lhs, int *rhs)
{
int sign = *lhs - *rhs;
// semantically this should be 'return 0;' but this condition is not
// supposed to trigger on our input data.
if (sign == 0) return 1;
return sign;
}
static int yes(void) __attribute__((noipa));
static int yes(void) { return 1; }
static int long_richcompare(int *self, int *other, int op)
__attribute__((noipa));
static int long_richcompare(int *self, int *other, int op)
{
int result;
if (!yes() || !yes())
return 0;
if (self == other)
result = 0;
else
result = cmp(self, other);
// has to force jump table
switch (op) {
// only 0 case is used on actual data
case 0: return (result == 0);
case 1: return 0;
case 3: return 0;
case 5: if (result == 0) return 1; else return 0;
default:
__builtin_unreachable();
}
}
#include
int main() {
int l = 2;
int r = 1;
int res = long_richcompare(&l, &r, 0);
printf("long_richcompare(2, 1, EQ) = %s (expect FALSE)\n", res ? "TRUE" :
"FALSE");
}
[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #1 from Sergei Trofimovich --- Created attachment 48814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48814&action=edit bug_test.c Selfcontained example.
[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #2 from Sergei Trofimovich --- Happens both on gcc-10.1.0 and gcc from main development branch. Here is the example of -O1/-O2 difference: $ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie -fno-stack-protector -O1 bug_test.c -o good-bug $ hppa2.0-unknown-linux-gnu-gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie -fno-stack-protector -O2 bug_test.c -o bad-bug $ ./good-bug long_richcompare(2, 1, EQ) = FALSE (expect FALSE) $ ./bad-bug long_richcompare(2, 1, EQ) = TRUE (expect FALSE) GCC was built as: $ hppa2.0-unknown-linux-gnu-gcc -v Reading specs from /home/slyfox/dev/git/gcc-hppa2.0/gcc/specs COLLECT_GCC=/home/slyfox/dev/git/gcc-hppa2.0/gcc/xgcc COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-hppa2.0/gcc/lto-wrapper Target: hppa2.0-unknown-linux-gnu Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=hppa2.0-unknown-linux-gnu --prefix=/home/slyfox/dev/git/gcc-hppa2.0/../gcc-hppa2.0-installed --with-sysroot=/usr/hppa2.0-unknown-linux-gnu --disable-bootstrap --enable-languages=c --disable-nls CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200701 (experimental) (GCC)
[Bug target/96015] [regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #3 from Sergei Trofimovich --- Reproducible on both qemu-hppa and on real "PA8600 (PCX-W+) 9000/785/C3600" machine.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #5 from Sergei Trofimovich --- I ran the test in qemu-hppa (qemu user binary emulation) against Gentoo's hppa2.0 root system as: /usr/bin/qemu-hppa -L /usr/hppa2.0-unknown-linux-gnu/ "$@" where /usr/hppa2.0-unknown-linux-gnu/ is a hppa SYSROOT. Cross-compiler is generated with Gentoo's 'crossdev' tool as: # crossdev hppa2.0-unknown-linux-gnu The command builds cross-binutils, cross-gcc with --sysroot=/usr/hppa2.0-unknown-linux-gnu/ and puts glibc into /usr/hppa2.0-unknown-linux-gnu/. Full native root system is also at http://distfiles.gentoo.org/releases/hppa/autobuilds/current-stage3-hppa2.0/ (stage3-hppa2.0-*.tar.bz2 tarballs). Should be good enough to be used for qemu-hppa as-is. I also plan to pass through the assembly dump this evening to get the idea where incorrect code got generated to spare you the debugging.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #6 from Sergei Trofimovich --- Created attachment 48816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48816&action=edit bad-bug.S bad-bug.S is miscompiled file generated by main gcc (not clear what is wrong yet). Generated as: $gcc/xgcc -B$gcc/gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie -fno-stack-protector -O2 -S bug_test.c -o bad-bug.S
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #9 from Sergei Trofimovich --- (In reply to Martin Liška from comment #7) > There's ASM diff in between GCC 9 and 10 version: > > diff -u good.s bad.s > --- good.s2020-07-01 15:04:58.315839436 +0200 > +++ bad.s 202 0-07-01 15:04:30.684040487 +0200 Hm, interesting! I think both these files are broken. Let's me try to elaborate b annotating bad-bug.S. All the test does is to print result of comparison of '2' and '1' stored in memory: *lhs = 2; *rhs = 1; int sign = *lhs - *rhs; return sign; But in bad-bug.S we never read from memory! (IPA is disabled to make functions somewhat opaque): """ main: ldi 2,%r28 stw %r2,-20(%r30) ldo 64(%r30),%r30 stw %r28,-52(%r30) ; store '2' in RAM ldo -56(%r30),%r19 ; get RAM address ldi 1,%r28 ldi 0,%r24 ; arg3 = '0' stw %r28,-56(%r30) ; store '1' in RAM copy %r19,%r25 ; arg1 = &2 bl long_richcompare,%r2 ldo -52(%r30),%r26 ; arg0 = &1 (delay slot, executed before branch) ... (all ok so far) long_richcompare: stw %r2,-20(%r30) stwm %r5,64(%r30) copy %r26,%r5; arg0 = &1 stw %r4,-60(%r30) copy %r25,%r4; arg1 = &2 stw %r3,-56(%r30) bl yes,%r2 copy %r24,%r3; arg2 = 0 (delay slot, is it safe in general to comiclr,= 0,%r28,%r0 ; if (!yes()) ... b,n .L22 ; go to actual comparison .L15: ldi 0,%r28 ; fall through to 'return 0;' (not interesting) .L3: .L26: ldw -84(%r30),%r2 ldw -60(%r30),%r4 ldw -56(%r30),%r3 bv %r0(%r2) ldwm -64(%r30),%r5 .L22: bl yes,%r2 nop comib,=,n 0,%r28,.L26 ; if ( .. || !yes()) return 0; (not interesting) ldi 0,%r28 comiclr,<< 5,%r3,%r0 ; check if 'arg3 < 5' to fit into jump table, otherwise skip (nullify) next instruction and run .L3 b,n .L25 ; handle jump table .L12: b .L3; return 0; (not interesting, fall through) ldi 1,%r28 .L25: ldil L'.L8,%r28; ldo R'.L8(%r28),%r28 ; load jump table address ldwx,s %r3(%r28),%r28 ; load target at .L8[arg2 * 4] bv,n %r0(%r28) ; jump on target, should be .L12 .section.rodata .align 4 .L8: .begin_brtab .word .L12 .word .L15 .word .L12 .word .L15 .word .L12 .word .L12 .end_brtab """ Note: during the whole execution at no point in time 'long_richcompare()' tried to dereference arg0 and arg1 inputs (%r4, %r5 registers). For comparison compiling with -O1 keeps the loads around: good-bug.S: """ main: ; same as above stw %r2,-20(%r30) ldo 64(%r30),%r30 ldi 2,%r28 stw %r28,-56(%r30) ldi 1,%r28 ldo -52(%r30),%r19 stw %r28,-52(%r30) ldi 0,%r24 copy %r19,%r25 bl long_richcompare,%r2 ldo -56(%r30),%r26 ... long_richcompare: stw %r2,-20(%r30) stwm %r5,64(%r30) stw %r4,-60(%r30) stw %r3,-56(%r30) copy %r26,%r4 ; arg0 copy %r25,%r3 ; arg1 bl yes,%r2 copy %r24,%r5 ; arg2 or,= %r28,%r0,%r28 ; result = 0 b,n .L11; .L2: ldw -84(%r30),%r2 .L12: ldw -60(%r30),%r4 ldw -56(%r30),%r3 bv %r0(%r2) ; return ldwm -64(%r30),%r5 .L11: bl yes,%r2 nop movb,= %r28,%r28,.L12 ; if(!yes()) return ... ldw -84(%r30),%r2 comb,=,n %r3,%r4,.L9 ; if(arg0 == arg1) (at branch) diff = 0; ldw 0(%r4),%r28 ldw 0(%r3),%r19 sub %r28,%r19,%r28; diff = *arg0 - *arg1 comiclr,<> 0,%r28,%r0 ldi 1,%r28 .L4: comiclr,>>= 5,%r5,%r0 b,n .L6 ldil L'.L7,%r19 ldo R'.L7(%r19),%r19 ldwx,s %r5(%r19),%r19 bv,n %r0(%r19); handle jump table, at .L8 .section.rodata .align 4 .L7: .begin_brtab .word .L8 .word .L10 .word .L6 .word .L10 .word .L6 .word .L6 .end_brtab .text .L9: b .L4 ldi 0,%r28 .L8: comiclr,<> 0,%r28,%r28; if (result == 0) ldi 1,%r28; result = 1; b .L12; return ldw -84(%r30),%r2 .L6: comiclr,<> 0,%r28,%r28 ldi 1,%r28 b .L12 ldw -84(%r30),%r2 .L10: b .L2 ldi 0,%r28 """
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #10 from Sergei Trofimovich --- Created attachment 48820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48820&action=edit good-bug.S
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #11 from Sergei Trofimovich ---
Looking at -fdump-tree-all:
$gcc/xgcc -B$gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O2 -S bug_test.c -o bad-bug.S -fdump-tree-all
I see that stores are eliminated at 'bad-bug.c.191t.cddce3' stage:
Was (at bad-bug.c.190t.dse3):
"""
__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
int sign;
int result;
int _1;
int _2;
int _5;
int prephitmp_6;
int _13;
int _16;
[local count: 1073741823]:
_1 = yes ();
if (_1 == 0)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 524844999]:
_2 = yes ();
if (_2 == 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 346397698]:
if (self_11(D) == other_12(D))
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 242478389]:
_13 = *self_11(D);
_16 = *other_12(D);
sign_17 = _13 - _16;
if (sign_17 == 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 160035736]:
goto ; [100.00%]
[local count: 103919309]:
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[33.33%], case 3: [33.33%], case 5: [16.67%]>
[local count: 23093180]:
:
goto ; [100.00%]
[local count: 115465900]:
# prephitmp_6 = PHI <0(13), 1(7)>
:
goto ; [100.00%]
[count: 0]:
:
__builtin_unreachable ();
[local count: 727344125]:
[local count: 1073741824]:
# _5 = PHI <0(13), prephitmp_6(9), 0(11), 0(8), 1(7)>
:
return _5;
[local count: 242478389]:
# result_21 = PHI <1(5), sign_17(6)>
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[50.00%], case 3: [50.00%], case 5: [50.00%]>
}
"""
Became (at bad-bug.c.191t.cddce3):
"""
Removing basic block 5
__attribute__((noipa, noinline, noclone, no_icf))
long_richcompare (int * self, int * other, int op)
{
int sign;
int result;
int _1;
int _2;
int _5;
int prephitmp_6;
[local count: 1073741823]:
_1 = yes ();
if (_1 == 0)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 524844999]:
_2 = yes ();
if (_2 == 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 346397698]:
if (self_11(D) == other_12(D))
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 103919309]:
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[33.33%], case 3: [33.33%], case 5: [16.67%]>
[local count: 23093180]:
:
goto ; [100.00%]
[local count: 115465900]:
# prephitmp_6 = PHI <0(11), 1(5)>
:
goto ; [100.00%]
[count: 0]:
:
__builtin_unreachable ();
[local count: 727344125]:
[local count: 1073741824]:
# _5 = PHI <0(11), prephitmp_6(7), 0(9), 0(6), 1(5)>
:
return _5;
[local count: 242478389]:
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[50.00%], case 3: [50.00%], case 5: [50.00%]>
}
"""
Note: the following block disappeared completely:
"""
[local count: 242478389]:
_13 = *self_11(D);
_16 = *other_12(D);
"""
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #14 from Sergei Trofimovich --- Created attachment 48821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48821&action=edit bad-bug.c.191t.cddce3 bad-bug.c.191t.cddce3 is the full file generated by -fdump-tree-all-all.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #15 from Sergei Trofimovich --- Created attachment 48822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48822&action=edit bad-bug.c.190t.dse3 bad-bug.c.190t.dse3 previous tree phase for comparison.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #16 from Sergei Trofimovich --- If I looks at bad-bug.c.190t.dse3 I see 'self' and 'other' refer to the same .MEM_10 memory location in 'basic block 5'. I think it should not, 'basic block 4' jumps into bb5 only when self != other. Do I read it correctly? ;; basic block 4, loop depth 0, count 346397698 (estimated locally), maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 3 [66.0% (guessed)] count:346397697 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (self_11(D) == other_12(D)) goto ; [30.00%] else goto ; [70.00%] ;;succ: 7 [30.0% (guessed)] count:103919308 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;5 [70.0% (guessed)] count:242478390 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 5, loop depth 0, count 242478389 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED) ;;pred: 4 [70.0% (guessed)] count:242478390 (estimated locally) (FALSE_VALUE,EXECUTABLE) # VUSE <.MEM_10> _13 = *self_11(D); # VUSE <.MEM_10> _16 = *other_12(D); sign_17 = _13 - _16; if (sign_17 == 0) goto ; [34.00%] else goto ; [66.00%] ;;succ: 13 [34.0% (guessed)] count:82442653 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;6 [66.0% (guessed)] count:160035736 (estimated locally) (FALSE_VALUE,EXECUTABLE)
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #19 from Sergei Trofimovich --- Created attachment 48827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48827&action=edit bad.S
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #20 from Sergei Trofimovich --- Created attachment 48828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48828&action=edit good.S
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #21 from Sergei Trofimovich --- (In reply to Eric Botcazou from comment #18) > If the control flow goes through .L12: > > .L12: > b .L3; return 0; (not interesting, fall through) > ldi 1,%r28 > > the return value will be 1 since ldi is in the delay slot of the branch. > > What happens if you compile with -O2 -fno-delayed-branch instead? Oh, -fno-delayed-branch makes test magically pass! Attaching both bad.S and good.S for comparison.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #22 from Sergei Trofimovich --- (In reply to Martin Liška from comment #17) > For me tree optimized dump is correct, so likely a target issue. Yeah, I agree. I finally understood why memory loads disappear (duh!). > @Sergei: Is GCC 9 working properly? > Would it be possible to bisect that? gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated optimization passes change the code enough. I'll try to cook up even smaller example given that -fno-delayed-branch seems to be a culprit and then bisect gcc.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #23 from Sergei Trofimovich ---
cvise managed to shrink example down to the following:
"""
int b, c;
int a() __attribute__((noipa));
int a(int *d, int *f, int g) {
int e;
if (d == f)
e = 0;
else
e = 1;
switch (g) {
case 0:
return e;
case 1:
case 3:
case 5:
if (e)
return 10;
default:
__builtin_unreachable();
}
}
int main() { return a(&b, &c, 0); }
"""
$ hppa2.0-unknown-linux-gnu-gcc -O2 bug_test.c -o bad; ./bad; echo $?
0
$ hppa2.0-unknown-linux-gnu-gcc -O2 bug_test.c -o good -fno-delayed-branch;
./good; echo $?
1
gcc-9.2.0 returns '1' in both cases. I'll bisect gcc against this example.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #24 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #23) > cvise managed to shrink example down to the following: For completeness assembly output difference is very clear now: $ hppa2.0-unknown-linux-gnu-gcc -O2 -S ../bug_test.c -o bug.S a: bv %r0(%r2) ldi 0,%r28 $ hppa2.0-unknown-linux-gnu-gcc -O2 -S ../bug_test.c -o bug.S -fno-delayed-branch a: comclr,<> %r26,%r25,%r0 b,n .L11 nop .L4: .L12: ldil L'.L6,%r28 ldo R'.L6(%r28),%r28 ldwx,s %r24(%r28),%r28 bv,n %r0(%r28) .section.rodata .align 4 .L6: .begin_brtab .word .L8 .word .L5 .word .L4 .word .L5 .word .L4 .word .L5 .end_brtab .text .L5: ldi 10,%r28 bv,n %r0(%r2) .L11: ldi 0,%r28 bv,n %r0(%r2) .L8: ldi 1,%r28 bv,n %r0(%r2)
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #25 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #22) > (In reply to Martin Liška from comment #17) > > For me tree optimized dump is correct, so likely a target issue. > > Yeah, I agree. I finally understood why memory loads disappear (duh!). > > > @Sergei: Is GCC 9 working properly? > > Would it be possible to bisect that? > > gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated > optimization passes change the code enough. > > I'll try to cook up even smaller example given that -fno-delayed-branch > seems to be a culprit and then bisect gcc. Bisected down to: $ git bisect good 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf Author: Martin Liska Date: Wed Dec 4 11:13:49 2019 +0100 Initialize a BB count in switch lowering. 2019-12-04 Martin Liska * tree-switch-conversion.c (switch_decision_tree::try_switch_expansion): Initialize count of newly created BB. From-SVN: r278959 gcc/ChangeLog| 5 + gcc/tree-switch-conversion.c | 1 + 2 files changed, 6 insertions(+)
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #27 from Sergei Trofimovich ---
If it's of any help by slightly expanding case switch I reproduced very similar
problem on both hppa and sh4 (but not on sparc or mips) with:
"""
int b, c;
int a() __attribute__((noipa));
int a(int *d, int *f, int g) {
int e;
if (d == f)
e = 0;
else
e = 1;
switch (g) {
case 0:
return e;
case 1:
return 7;
case 2:
return 8;
case 3:
return 8;
case 4:
return 1;
case 5:
if (e)
return 10;
default:
__builtin_unreachable();
}
}
int main() { return a(&b, &c, 0); }
"""
$ sh4-unknown-linux-gnu-gcc -fno-PIE -no-pie -fno-stack-protector
-U_FORTIFY_SOURCE -O2 bug_test.c -o bad-bug; ./bad-bug; echo $?
8
$ sh4-unknown-linux-gnu-gcc -fno-PIE -no-pie -fno-stack-protector
-U_FORTIFY_SOURCE -O2 -fno-delayed-branch bug_test.c -o good-bug; ./good-bug;
echo $?
1
bad-bug.S:
a:
cmp/eq r4,r5 ; if (d == f) // not our case
bt/s.L21 ; goto .L21; something complicated on jump tables
mov #5,r1 ; +delay slot
.L6:
.align 1
.L13:
.align 1
.L14:
rts; return 8
mov #8,r0 ; +delay slot
.align 1
.L17:
rts
mov #1,r0
.align 1
.L21:
mov #4,r1
cmp/hi r1,r6
bt/s.L6
mov r6,r2
mova.L8,r0
add r2,r2
mov.w @(r0,r2),r1
brafr1
nop
.L9:
.align 2
.L8:
.word .L10-.L9
.word .L15-.L9
.word .L14-.L9
.word .L14-.L9
.word .L17-.L9
.align 1
.L15:
rts
mov #7,r0
.align 1
.L10:
rts
mov r6,r0
good-bug.S:
a:
cmp/eq r4,r5
bt .L21
mov #5,r1
cmp/hi r1,r6
bf .L22
.L6:
.align 1
.L22:
mova.L12,r0
mov.b @(r0,r6),r6
brafr6
nop
.L13:
.align 2
.L12:
.byte .L17-.L13
.byte .L15-.L13
.byte .L14-.L13
.byte .L14-.L13
.byte .L17-.L13
.byte .L11-.L13
.align 1
.L14:
mov #8,r0
rts
nop
.align 1
.L17:
mov #1,r0
rts
nop
.align 1
.L21:
mov #4,r1
cmp/hi r1,r6
bt .L6
mova.L8,r0
mov r6,r2
add r2,r2
mov.w @(r0,r2),r1
brafr1
nop
.L9:
.align 2
.L8:
.word .L10-.L9
.word .L15-.L9
.word .L14-.L9
.word .L14-.L9
.word .L17-.L9
.align 1
.L15:
mov #7,r0
rts
nop
.align 1
.L11:
mov #10,r0
rts
nop
.align 1
.L10:
mov r6,r0
rts
nop
Might be not backend-specific? Or pa and sh have a similar bug.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #31 from Sergei Trofimovich --- (In reply to Martin Liška from comment #28) > > Bisected down to: > > > > $ git bisect good > > 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit > > commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf > > Author: Martin Liska > > Date: Wed Dec 4 11:13:49 2019 +0100 > > > > Initialize a BB count in switch lowering. > Thank you for the bisection. However, this one is not a culprit commit, it > only made it visible. > Let's wait for can Erik find out. For my own curiosity I applied "Initialize a BB count in switch lowering." to gcc-9 and found that it's indeed is already broken. I attempted a bisection between gcc-8 and gcc-9 while applying this patch to get the idea where it surfaced. Got arrived at: $ git bisect good 9427422ddacdf1c2914adfb6e8edca87f250fdfc is the first bad commit commit 9427422ddacdf1c2914adfb6e8edca87f250fdfc Author: Jeff Law Date: Wed Apr 3 10:03:37 2019 -0600 re PR rtl-optimization/81025 (gcc ICE while building glibc for MIPS soft-float multi-lib variant) PR rtl-optimization/81025 * reorg.c (skip_consecutive_labels): Do not skip past a BARRIER. From-SVN: r270129 gcc/ChangeLog | 5 + gcc/reorg.c | 15 ++- 2 files changed, 19 insertions(+), 1 deletion(-) https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9427422ddacdf1c2914adfb6e8edca87f250fdfc
[Bug c++/96107] New: [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96107
Bug ID: 96107
Summary: [11 regression] ICE on invalid c++: "Error reporting
routines re-entered." when using -Wall
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
$ cat bug.cc
struct a {
using b = a;
class c f(, b , (c *, *{ int d;
b e;
f(d, e, [](auto, *))
Internal compiler error: Error reporting routines re-entered.
0x7aa464 check_nonnull_arg
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5523
0x7aa464 check_nonnull_arg
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5498
0x7d12c6 check_function_nonnull
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5315
0x7d12c6 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5764
0x624e9b build_over_call
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/call.c:8868
0x626cc4 build_new_method_call_1
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/call.c:10348
0x6276bf build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/call.c:10423
0x7423e5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/pt.c:20042
0x7437ff tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/pt.c:15913
0x7437ff tsubst(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/pt.c:15913
0x6a56e5 dump_template_bindings
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:416
0x6a5907 dump_substitution
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:1562
0x6a5907 dump_substitution
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:1550
0x6a0b0c dump_function_decl
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:1720
0x6a6998 decl_to_string
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:3101
0x6a6998 cp_printer
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:4261
0x15b8bbe pp_format(pretty_printer*, text_info*)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/pretty-print.c:1475
0x15ace42 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/diagnostic.c:1159
0x15af5fd diagnostic_impl
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/diagnostic.c:1309
0x15af5fd inform(unsigned int, char const*, ...)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/diagnostic.c:1388
For comparison gcc-10.1.0 does not crash:
$ /usr/bin/x86_64-pc-linux-gnu-g++-10.1.0 -o bug.o -c -Wall bug.cc
[Bug c++/96107] [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96107 --- Comment #1 from Sergei Trofimovich --- Forgot to post actual command. It's the same as for 10.1.0: $ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++ -o bug.o -c -Wall bug.cc
[Bug c++/96107] [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96107 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Sergei Trofimovich --- Today's gcc does not crash. Bisected fix down to: commit 67a493a0b9e7ce6caba4b8bedf1f3295e477ec00 Author: Martin Sebor Date: Mon Jul 6 15:23:37 2020 -0600 Exclude calls to variadic lambda stubs from -Wnonnull checking (PR c++/95984). Resolves: PR c++/95984 - Internal compiler error: Error reporting routines re-entered in -Wnonnull on a variadic lamnda PR c++/96021 - missing -Wnonnull passing nullptr to a nonnull variadic lambda *** This bug has been marked as a duplicate of bug 95984 ***
[Bug c++/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95984 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #6 from Sergei Trofimovich --- *** Bug 96107 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96003] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment #3 from Sergei Trofimovich ---
Don't know if it's the same problem, but firefox-78 also fails to build with
'-Werror=nonnull' seeming false positives.
cvise produced the following example:
$ cat bug.cpp
struct a {
void b();
};
struct c {
template class e {
public:
int operator*();
void operator++() { d()->b(); }
bool operator!=(e);
};
e begin();
e end();
};
class f {
c g;
void h();
};
void f::h() {
for (auto i : g)
;
}
$ x86_64-pc-linux-gnu-g++-10.1.0 -o bug.o -c bug.cpp -std=c++17 -Werror=nonnull
-Wno-unused-variable -O0 -fsyntax-only
$ /home/slyfox/dev/git/gcc-native-quick/gcc/xg++ -B
/home/slyfox/dev/git/gcc-native-quick/gcc -o bug.o -c bug.cpp -std=c++17
-Werror=nonnull -Wno-unused-variable -O0 -fsyntax-only
bug.cpp: In instantiation of 'void c::e::operator++() [with d = a*]':
bug.cpp:19:17: required from here
bug.cpp:8:31: error: 'this' pointer null [-Werror=nonnull]
8 | void operator++() { d()->b(); }
| ~~^~
bug.cpp:2:8: note: in a call to non-static member function 'void a::b()'
2 | void b();
|^
cc1plus: some warnings being treated as errors
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 --- Comment #6 from Sergei Trofimovich --- (In reply to Martin Sebor from comment #4) > The warning in the test case in comment #3 looks correct to me. Thank you! I'll try to re-reduce and not introduce new NULLs.
[Bug driver/81658] gcc configured with --enable-default-pie on SPARC produces buggy executable from working .o files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81658 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #1 from Sergei Trofimovich --- I think it was a https://sourceware.org/PR22638
[Bug driver/96190] New: --enable-default-pie on sparc uses crtbeginS.o (correct) and crtend.o (incorrect)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96190
Bug ID: 96190
Summary: --enable-default-pie on sparc uses crtbeginS.o
(correct) and crtend.o (incorrect)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The side-effect of the crtbeginS.o/crtend.o mismatch are:
- R_SPARC_NONE relocations in final executables: https://sourceware.org/PR26236
- TEXTRELs in binaries
Simple reproducer:
$ echo 'int main(){}' | sparc-unknown-linux-gnu-gcc -x c - -o a
/usr/libexec/gcc/sparc-unknown-linux-gnu/ld: warning: creating a DT_TEXTREL in
object
$ echo 'int main(){}' | sparc-unknown-linux-gnu-gcc -x c - -o a -no-pie
$ echo 'int main(){}' | sparc-unknown-linux-gnu-gcc -x c - -o a -pie
gcc is built as:
"""
Using built-in specs.
COLLECT_GCC=/usr/bin/sparc-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc-unknown-linux-gnu/10.1.0/lto-wrapper
Target: sparc-unknown-linux-gnu
Configured with:
/tmp/portage-tmpdir/portage/cross-sparc-unknown-linux-gnu/gcc-10.1.0-r2/work/gcc-10.1.0/configure
--host=x86_64-pc-linux-gnu --target=sparc-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/sparc-unknown-linux-gnu/gcc-bin/10.1.0
--includedir=/usr/lib/gcc/sparc-unknown-linux-gnu/10.1.0/include
--datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/10.1.0
--mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/10.1.0/man
--infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/10.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/sparc-unknown-linux-gnu/10.1.0/include/g++-v10
--with-python-dir=/share/gcc-data/sparc-unknown-linux-gnu/10.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 10.1.0-r2 p3' --disable-esp --enable-libstdcxx-time
--enable-poison-system-directories --with-sysroot=/usr/sparc-unknown-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--enable-vtable-verify --without-zstd --enable-lto --without-isl
--enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (Gentoo 10.1.0-r2 p3)
"""
I think the bug here is in SPEC files where crtendS.o is only pulled by
explicit options:
gcc/config/sparc/linux.h: "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
gcc/config/sparc/linux64.h: "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
AFAIu it should be something similar to generic case:
gcc/config/gnu-user.h: shared|static-pie|" PIE_SPEC ":crtendS.o%s; \
Does it sound about right? Should other targets follow as well? Specifically:
gcc/config/alpha/linux.h: crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/alpha/linux.h: crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/alpha/linux.h: %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
gcc/config/bfin/linux.h: crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/c6x/uclinux-elf.h: "%{!shared:crt1%O%s} crti%O%s
%{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/csky/csky-linux-elf.h: crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/csky/csky-linux-elf.h: "%{shared|pie:crtendS.o%s;:crtend.o%s}
crtn.o%s"
gcc/config/frv/linux.h: crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/frv/linux.h: "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
gcc/config/ia64/linux.h: crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/ia64/linux.h: crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/ia64/linux.h: %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
gcc/config/m32r/linux.h: crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/m32r/linux.h: "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
gcc/config/sparc/linux.h: "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
gcc/config/sparc/linux64.h: "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
[Bug target/96190] --enable-default-pie on sparc uses crtbeginS.o (correct) and crtend.o (incorrect)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96190 --- Comment #1 from Sergei Trofimovich --- Sent https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549983.html for review. If it's a reasonable thing to do I'll convert the rest of targets.
[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
--- Comment #3 from Sergei Trofimovich ---
Another example is edb-debugger project
https://github.com/eteran/edb-debugger/blob/070d0196227a58ce2ba15c695944ba16ce66c080/plugins/DebuggerCore/unix/linux/arch/x86-generic/PlatformThread.cpp#L331:
long PlatformThread::setDebugRegister(std::size_t n, unsigned long value) {
return ptrace(PTRACE_POKEUSER, tid_, offsetof(struct user,
u_debugreg[n]), value);
}
Fails build on gcc-11 as:
edb-debugger/plugins/DebuggerCore/unix/linux/arch/x86-generic/PlatformThread.cpp:331:72:
error: 'n' is not a constant expression
331 | return ptrace(PTRACE_POKEUSER, tid_, offsetof(struct user,
u_debugreg[n]), value);
| ^
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #7 from Sergei Trofimovich ---
Similar example from xmms2 project, dynamic_cast<> version:
#include
// main loop interface
struct I {
virtual void run();
};
struct M : public I {
virtual void run();
void setup_M();
};
struct Client
{
// In real code Client() always initializes mainloop_ with non-NULL 'M*'
pointer;
I* mainloop_;
Client();
void run_client();
void connect() {
if (mainloop_ && typeid(mainloop_) == typeid(M)) {
dynamic_cast(mainloop_)->setup_M( );
}
}
};
$ LANG=C x86_64-pc-linux-gnu-g++-11.0.0 -c bug.cpp -o a.o -Werror=nonnull
bug.cpp: In member function 'void Client::connect()':
bug.cpp:22:49: error: 'this' pointer null [-Werror=nonnull]
22 | dynamic_cast(mainloop_)->setup_M( );
| ^
bug.cpp:10:10: note: in a call to non-static member function 'void
M::setup_M()'
10 | void setup_M();
| ^~~
cc1plus: some warnings being treated as errors
Original code is from
https://github.com/xmms2/xmms2-devel/blob/dedc33d7408e140bce714c2c3eb5bcc793f1af6c/src/clients/lib/xmmsclient%2B%2B/client.cpp#L85
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #8 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #6)
> (In reply to Martin Sebor from comment #4)
> > The warning in the test case in comment #3 looks correct to me.
>
> Thank you! I'll try to re-reduce and not introduce new NULLs.
Here is the second attempt at reducing firefox case, also related to
static_cast<>:
struct D;
struct B {
B* next;
D* Next();
};
struct D : public B {
virtual ~D();
};
struct Iterator {
D* current;
void advance() {
current = static_cast(current)->Next();
}
};
$ x86_64-pc-linux-gnu-g++ -o bug.o -c bug.cpp -Werror=nonnull
-fno-strict-aliasing
bug.cpp: In member function 'void Iterator::advance()':
bug.cpp:14:46: error: 'this' pointer null [-Werror=nonnull]
14 | current = static_cast(current)->Next();
| ^
bug.cpp:4:6: note: in a call to non-static member function 'D* B::Next()'
4 | D* Next();
| ^~~~
cc1plus: some warnings being treated as errors
Also, the "'this' pointer null" error wording is not very clear. Should it be
"'this' pointer is null"? Or "'this' pointer may be null"?
[Bug target/96190] --enable-default-pie on sparc uses crtbeginS.o (correct) and crtend.o (incorrect)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96190 --- Comment #3 from Sergei Trofimovich --- As suggested by Eric I plan to apply sparc fix from master into gcc-10 branch after 10.2 release cut.
[Bug lto/96291] New: -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291
Bug ID: 96291
Summary: -flto fails as "internal compiler error: Segmentation
fault" during IPA pass: cp
incall_for_symbol_thunks_and_aliases()
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Originally reported by Gabriel Marcano as https://bugs.gentoo.org/733482 where
radare-4.5.0 ICEs gcc if that is built with -flto.
ICE is reproducible on both gcc-10 and gcc-11. Here is the minimal(ish)
reproducer:
// cat sdb.c
int b;
void a();
void sdb_ns_free();
void c(int d) {
sdb_ns_free();
a(b, 0);
}
void sdb_free() { c(0); }
// cat ns.c
void sdb_free();
void sdb_ns_free() { sdb_free(); }
// cat main.c
void sdb_free();
void a() { sdb_free(); }
$ x86_64-pc-linux-gnu-gcc -c -O2 -flto -o sdb.o sdb.c
$ x86_64-pc-linux-gnu-gcc -c -O2 -flto -o ns.o ns.c
$ x86_64-pc-linux-gnu-gcc -c -O2 -flto -O0 -o main.o main.c
$+ x86_64-pc-linux-gnu-gcc -O2 -flto -o sdb main.o sdb.o ns.o
during IPA pass: cp
lto1: internal compiler error: Segmentation fault
0xa6d3df crash_signal
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/toplev.c:328
0x7f1656e35c3f ???
/usr/src/debug/sys-libs/glibc-2.31-r6/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x5d4751 has_undead_caller_from_outside_scc_p
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-cp.c:5670
0x680054 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cgraph.c:2450
0x12fe86d identify_dead_nodes
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-cp.c:5687
0x12fe86d ipcp_decision_stage
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-cp.c:5730
0x12fe86d ipcp_driver
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-cp.c:5908
0x12fe86d execute
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-cp.c:5999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
lto-wrapper: fatal error: /usr/bin/x86_64-pc-linux-gnu-gcc returned 1 exit
status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291 --- Comment #4 from Sergei Trofimovich --- Peeking at the crash: """ Program received signal SIGSEGV, Segmentation fault. 0x01ca0fed in has_undead_caller_from_outside_scc_p (node=0x77670438, data=0x0) at ../../gcc/gcc/ipa-cp.c:5670 5670 && !IPA_NODE_REF (cs->caller)->node_dead) (gdb) list 5665if (cs->caller->thunk.thunk_p 5666&& cs->caller->call_for_symbol_thunks_and_aliases 5667 (has_undead_caller_from_outside_scc_p, NULL, true)) 5668 return true; 5669else if (!ipa_edge_within_scc (cs) 5670 && !IPA_NODE_REF (cs->caller)->node_dead) 5671 return true; 5672 return false; 5673} 5674 (gdb) print IPA_NODE_REF(cs->caller) $1 = (ipa_node_params *) 0x0 """ Is it an expected invariant? Looks like most of code does not expect NULL there: $ git grep IPA_NODE_REF | fgrep NULL gcc/ipa-prop.c: && IPA_NODE_REF (node) != NULL) gcc/ipa-prop.c: && IPA_NODE_REF (node) != NULL)
[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291
--- Comment #5 from Sergei Trofimovich ---
I shrunk example to "single-file" (almost) example to ease local tweaking:
$ cat 1file.c
void e(void);
void f(void);
void a(int, int);
void c(int);
#ifdef COMPILE_F1
int b;
void c(int d) {
f();
a(b, 0);
}
void e(void) { c(0); }
#endif
#ifdef COMPILE_F2
void f(void) { c(0); }
#endif
#ifdef COMPILE_F3
void a(int a1, int a2) { e(); }
#endif
$ x86_64-pc-linux-gnu-gcc -c -O2 -flto -o f1.o 1file.c -DCOMPILE_F1
$ x86_64-pc-linux-gnu-gcc -c -O2 -flto -o f2.o 1file.c -DCOMPILE_F2
$ x86_64-pc-linux-gnu-gcc -c -O2 -flto -O0 -o f3.o 1file.c -DCOMPILE_F3
$ x86_64-pc-linux-gnu-gcc -O2 -flto -o sdb f1.o f2.o f3.o
during IPA pass: cp
lto1: internal compiler error: Segmentation fault
[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291 --- Comment #6 from Sergei Trofimovich --- -fdump-ipa-all-all generates sdb.wpa.076i.cp that says f() has no jump functions: """ Jump functions: Jump functions of caller main/9: Jump functions of caller a/8: callsite a/8 -> e/2 : no arg info Jump functions of caller f/6: Jump functions of caller e/2: callsite e/2 -> c/1 : param 0: CONST: 0 value: 0x0, mask: 0x0 Unknown VR Jump functions of caller c/1: callsite c/1 -> a/8 : param 0: UNKNOWN value: 0x0, mask: 0x Unknown VR param 1: UNKNOWN value: 0x0, mask: 0x Unknown VR callsite c/1 -> f/6 : no arg info """ Is it expected?
[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291 --- Comment #7 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #6) > -fdump-ipa-all-all generates sdb.wpa.076i.cp that says f() has no jump > functions: > ... > Is it expected? print_all_lattices() suggests it is expected for unoptimized cases to have no IPA info: """ info = IPA_NODE_REF (node); /* Skip unoptimized functions and constprop clones since we don't make lattices for them. */ if (!info || info->ipcp_orig_node) continue; """ The crash happens when analysing a()->e() edge. But a() was compiled with -flto -O0 and thus has no IPA fnsummary. Proposed patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550667.html
[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment #7 from Sergei Trofimovich ---
Not sure if it's the same bug or not, but I get the same error building GHC for
SH4. Reproducible on gcc-master and on gcc-9.2.0.
Here is the minimal reproducer extracted by creduce:
$ cat bug.c
/*
works:
$ sh4-unknown-linux-gnu-gcc-o bug.o -c bug.c
fails:
$ sh4-unknown-linux-gnu-gcc -O -o bug.o -c bug.c
error:
error: unable to find a register to spill in class 'R0_REGS'
*/
inline int a(char *b, char c) { __sync_val_compare_and_swap(b, c, 0); }
int d(void) {
while (1) {
char e;
a(&e, e);
}
}
$ LANG=C sh4-unknown-linux-gnu-gcc-o bug.o -c bug.c
$ LANG=C sh4-unknown-linux-gnu-gcc -O -o bug.o -c bug.c
bug.c: In function 'd':
bug.c:15:1: error: unable to find a register to spill in class 'R0_REGS'
15 | }
| ^
bug.c:15:1: error: this is the insn:
(insn 18 13 41 4 (parallel [
(set (subreg:SI (reg:QI 6 r6 [174]) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 2 r2 [176]) [-1 S1 A8])
(reg:QI 173 [ e ])
(reg:QI 3 r3 [177])
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 2 r2 [176]) [-1 S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
]) "bug.c":9:33 401 {atomic_compare_and_swapqi_soft_gusa}
(expr_list:REG_DEAD (reg:QI 173 [ e ])
(expr_list:REG_UNUSED (reg:QI 6 r6 [174])
(expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))
bug.c:15: confused by earlier errors, bailing out
$ ./xgcc -B. -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: sh4-unknown-linux-gnu
Configured with: ../gcc/configure --target=sh4-unknown-linux-gnu
--prefix=/home/slyfox/dev/git/gcc-sh4/../gcc-sh4-installed
--with-sysroot=/usr/sh4-unknown-linux-gnu --disable-bootstrap
--enable-languages=c --disable-nls CFLAGS=-O0 CXXFLAGS=-O0
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191103 (experimental) (GCC)
[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 --- Comment #8 from Sergei Trofimovich --- Created attachment 47159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47159&action=edit bug.c
[Bug c++/92504] New: ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504
Bug ID: 92504
Summary: ICE on gcc-9 -fopenmp: internal compiler error: tree
check: expected tree that contains 'decl common'
structure, have 'baselink' in get_inner_reference, at
expr.c:7238
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Original bug is reported at https://bugs.gentoo.org/699938 by Marc Vinyals
where invalid C++ code crashes gcc with internal error instead of error
message.
creduce turned it into the following:
// $ cat bug.ii
class c {
void d();
};
main() {
c a;
#pragma omp for
for (auto b = a; b != a.d; b)
;
Note: there is no closing bracket and for contents is quite invalid. gcc-master
files like that:
$ gcc/xg++ -Bgcc -O1 -fopenmp -c bug.ii -o bug.o
bug.ii:4:1: warning: ISO C++ forbids declaration of 'main' with no type
[-Wreturn-type]
4 | main() {
| ^~~~
bug.ii: In function 'int main()':
bug.ii:8:5: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
8 | ;
| ^
0x7f1fd53edf1a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
gcc is built as:
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xg++
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,lto
--disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl CFLAGS='-O1 ' CXXFLAGS='-O1 '
--with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191113 (experimental) (GCC)
[Bug c++/92504] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 --- Comment #1 from Sergei Trofimovich --- Created attachment 47232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47232&action=edit bug.ii
[Bug c++/92504] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504
--- Comment #4 from Sergei Trofimovich ---
If I read backtrace function names correctly crash happened when openmp for was
expanded and one of arguments was not recognised early enough as invalid (value
vs. function pointer?).
Thread 2.1 "cc1plus" hit Breakpoint 1, internal_error
(gmsgid=gmsgid@entry=0x1c53558 "tree check: expected tree that contains %qs
structure, have %qs in %s, at %s:%d")
at ../../gcc/gcc/diagnostic.c:1577
1577{
(gdb) bt
#0 internal_error (gmsgid=gmsgid@entry=0x1c53558 "tree check: expected tree
that contains %qs structure, have %qs in %s, at %s:%d") at
../../gcc/gcc/diagnostic.c:1577
#1 0x011f74ff in tree_contains_struct_check_failed
(node=node@entry=0x7785ecf0, en=en@entry=TS_DECL_COMMON,
file=file@entry=0x1bc5954 "../../gcc/gcc/expr.c",
line=line@entry=7238, function=function@entry=0x1bc5b35
"get_inner_reference") at ../../gcc/gcc/tree.c:9858
#2 0x00ac66a5 in contains_struct_check (__g=0x1bc5b35
"get_inner_reference", __l=7238, __f=0x1bc5954 "../../gcc/gcc/expr.c",
__s=TS_DECL_COMMON, __t=0x7785ecf0)
at ../../gcc/gcc/tree.h:3387
#3 get_inner_reference (exp=exp@entry=0x7785ed20,
pbitsize=pbitsize@entry=0x7fffc1c0, pbitpos=pbitpos@entry=0x7fffc1a0,
poffset=poffset@entry=0x7fffc198,
pmode=pmode@entry=0x7fffc148,
punsignedp=punsignedp@entry=0x7fffc158, preversep=0x7fffc168,
pvolatilep=0x7fffc178) at ../../gcc/gcc/expr.c:7238
#4 0x00b1d0bd in optimize_bit_field_compare (rhs=0x77ffbc60,
lhs=0x7785ed20, compare_type=0x7787eb28, code=NE_EXPR, loc=2147483649)
at ../../gcc/gcc/fold-const.c:4443
#5 fold_binary_loc (loc=loc@entry=2147483649, code=code@entry=NE_EXPR,
type=type@entry=0x7787eb28, op0=op0@entry=0x7785ed20,
op1=op1@entry=0x77ffbc60)
at ../../gcc/gcc/fold-const.c:11091
#6 0x00b209f4 in fold_build2_loc (loc=loc@entry=2147483649,
code=code@entry=NE_EXPR, type=type@entry=0x7787eb28,
op0=op0@entry=0x7785ed20,
op1=op1@entry=0x77ffbc60) at ../../gcc/gcc/fold-const.c:12720
#7 0x00b17862 in fold_binary_loc (loc=2147483649, code=NE_EXPR,
type=0x7787eb28, op0=0x77ffbc60, op1=0x7785ed20) at
../../gcc/gcc/fold-const.c:9729
#8 0x00b3fce2 in fold (expr=expr@entry=0x779c8ca8) at
../../gcc/gcc/fold-const.c:12342
#9 0x00652a56 in cp_fold (x=) at
../../gcc/gcc/cp/cp-gimplify.c:2534
#10 0x00654ca2 in cp_fold_maybe_rvalue (x=,
rval=rval@entry=true) at ../../gcc/gcc/cp/cp-gimplify.c:2210
#11 0x00654d41 in cp_fold_rvalue (x=) at
../../gcc/gcc/cp/cp-gimplify.c:2233
#12 0x00654d8e in cp_fully_fold (x=,
x@entry=0x779c8ca8) at ../../gcc/gcc/cp/cp-gimplify.c:2257
#13 0x008214b7 in handle_omp_for_class_iterator (i=i@entry=0,
locus=locus@entry=24706, code=code@entry=OMP_FOR,
declv=declv@entry=0x779b8ae0,
orig_declv=orig_declv@entry=0x779b8d20,
initv=initv@entry=0x779b8b00, condv=0x779b8b20, incrv=0x779b8b40,
body=0x7fffc818, pre_body=0x7fffc810,
clauses=@0x7fffc808: 0x0, collapse=1, ordered=0) at
../../gcc/gcc/cp/semantics.c:8437
#14 0x00834bb6 in finish_omp_for (locus=locus@entry=24706,
code=code@entry=OMP_FOR, declv=declv@entry=0x779b8ae0,
orig_declv=0x779b8d20, orig_declv@entry=0x0,
initv=initv@entry=0x779b8b00, condv=condv@entry=0x779b8b20,
incrv=0x779b8b40, body=, pre_body=,
orig_inits=0x7fffc9a0,
clauses=) at ../../gcc/gcc/cp/semantics.c:8948
#15 0x0077db3f in cp_parser_omp_for_loop
(parser=parser@entry=0x7788e7b8, code=code@entry=OMP_FOR,
clauses=, clauses@entry=0x0,
cclauses=cclauses@entry=0x0, if_p=if_p@entry=0x0) at
../../gcc/gcc/cp/parser.c:38279
#16 0x0077e4e1 in cp_parser_omp_for
(parser=parser@entry=0x7788e7b8,
pragma_tok=pragma_tok@entry=0x777de118, p_name=,
p_name@entry=0x7fffcb90 "#pragma omp for", mask=...,
cclauses=cclauses@entry=0x0, if_p=0x0) at ../../gcc/gcc/cp/parser.c:38526
#17 0x00780f2d in cp_parser_omp_construct
(parser=parser@entry=0x7788e7b8,
pragma_tok=pragma_tok@entry=0x777de118, if_p=if_p@entry=0x0)
at ../../gcc/gcc/cp/parser.c:42102
#18 0x00759509 in cp_parser_pragma (parser=parser@entry=0x7788e7b8,
context=context@entry=pragma_compound, if_p=if_p@entry=0x0) at
../../gcc/gcc/cp/parser.c:42763
#19 0x0075b59f in cp_parser_statement
(parser=parser@entry=0x7788e7b8,
in_statement_expr=in_statement_expr@entry=0x0,
in_compound=in_compound@entry=true,
if_p=if_p@entry=0x0, chain=chain@entry=0x0,
loc_after_labels=loc_after_labels@entry=0x0) at ../../gcc/gcc/cp/parser.c:11354
#20 0x0075b80c in cp_parser_statement_seq_opt
(parser=parser@entry=0x7788e7b8,
in_statement_expr=in_statement_expr@entry=0x0) at
../../gcc/gcc/cp/parser.c:11742
#21 0x0075b8e1 in cp_parser_compound_statement
(parser=parser@entry=0x7788e7b8,
in_statement_exp
[Bug middle-end/92945] New: -O2 -floop-nest-optimize crashes gccin isl_basic_map_underlying_set ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92945 Bug ID: 92945 Summary: -O2 -floop-nest-optimize crashes gccin isl_basic_map_underlying_set () Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Created attachment 47498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47498&action=edit scipy-graphite-ice.f Initially reported as https://bugs.gentoo.org/702968 by wolfwood. There fortran code (from scipy-1.1.0) and C++ code (from dav1d-0.5.2) crash with -floop-nest-optimize. I crash both gcc-9.2.0 and current gcc trunk. Here is the reduced fortran example: $ cat scipy-graphite-ice.f SUBROUTINE CERZO(NT,ZO) IMPLICIT DOUBLE PRECISION (E,P,W) IMPLICIT COMPLEX *16 (C,Z) DIMENSION ZO(NT) DO 35 NR=1,NT PX=0.5*PU-0.5*DLOG(PV)/PU PY=0.5*PU+0.5*DLOG(PV)/PU 15 IT=IT+1 CALL CERF(Z,ZF,ZD) DO 30 I=1,NR-1 ZW=(1.0D0,0.0D0) DO 25 J=1,NR-1 IF (J.EQ.I) GO TO 25 ZW=ZW*(Z-ZO(J)) 25CONTINUE 30ZQ=ZQ+ZW ZGD=(ZD-ZQ*ZFD)/ZP Z=Z-ZFD/ZGD IF (IT.LE.50.AND.DABS((W-W0)/W).GT.1.0D-11) GO TO 15 35 ZO(NR)=Z IF (B.NE.INT(B)) THEN ENDIF END $ LANG=C ./gfortran -B . -O2 -floop-nest-optimize -c scipy-graphite-ice.f scipy-graphite-ice.f:16:72: 16 | 30ZQ=ZQ+ZW | 1 Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 30 at (1) scipy-graphite-ice.f:20:72: 20 | 35 ZO(NR)=Z | 1 Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 35 at (1) during GIMPLE pass: graphite scipy-graphite-ice.f:1:0: 1 | SUBROUTINE CERZO(NT,ZO) | internal compiler error: Segmentation fault 0x7fda773f51cf ??? /usr/src/debug/sys-libs/glibc-2.30-r3/glibc-2.30/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7fda773def1a __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ LANG=C ./gfortran -B . -v Reading specs from ./specs COLLECT_GCC=./gfortran COLLECT_LTO_WRAPPER=./lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-fortran-and-isl/../gcc-native-quick-installed --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu --enable-languages=c,c++,fortran --with-isl Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20191215 (experimental) (GCC)
[Bug middle-end/92945] -O2 -floop-nest-optimize crashes gccin isl_basic_map_underlying_set ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92945 --- Comment #1 from Sergei Trofimovich --- The crash happens somewhere in internals of isl-0.22: Thread 2.1 "f951" received signal SIGSEGV, Segmentation fault. [Switching to process 1919154] 0x77e50a74 in isl_basic_map_underlying_set () from /usr/lib64/libisl.so.22 (gdb) bt #0 0x77e50a74 in isl_basic_map_underlying_set () from /usr/lib64/libisl.so.22 #1 0x77e56431 in isl_basic_map_is_empty () from /usr/lib64/libisl.so.22 #2 0x77e578da in ?? () from /usr/lib64/libisl.so.22 #3 0x77e2ede3 in ?? () from /usr/lib64/libisl.so.22 #4 0x77e3115c in ?? () from /usr/lib64/libisl.so.22 #5 0x77e326ac in isl_union_access_info_compute_flow () from /usr/lib64/libisl.so.22 #6 0x017b5b9e in scop_get_dependences(scop*) () #7 0x017b603b in apply_poly_transforms(scop*) () #8 0x017b02d2 in graphite_transform_loops() () #9 0x017b0809 in (anonymous namespace)::pass_graphite_transforms::execute(function*) () #10 0x00c0caed in execute_one_pass(opt_pass*) () #11 0x00c0d50f in execute_pass_list_1(opt_pass*) () #12 0x00c0d521 in execute_pass_list_1(opt_pass*) () #13 0x00c0d521 in execute_pass_list_1(opt_pass*) () #14 0x00c0d521 in execute_pass_list_1(opt_pass*) () #15 0x00c0d53a in execute_pass_list(function*, opt_pass*) () #16 0x0080d779 in cgraph_node::expand() () #17 0x0080f2c2 in symbol_table::compile() () #18 0x008117ba in symbol_table::finalize_compilation_unit() () #19 0x00cfab26 in compile_file() () #20 0x00cfd784 in toplev::main(int, char**) () #21 0x018f083c in main ()
[Bug middle-end/92945] -O2 -floop-nest-optimize crashes gccin isl_basic_map_underlying_set ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92945 --- Comment #2 from Sergei Trofimovich --- Rebuilt isl with debugging symbols. gdb says 'bmap' is NULL: Thread 2.1 "f951" received signal SIGSEGV, Segmentation fault. [Switching to process 1944963] isl_basic_map_underlying_set (bmap=0x0) at ../isl-0.22/isl_map.c:5515 5515space = isl_space_underlying(space, bmap->n_div); (gdb) bt #0 isl_basic_map_underlying_set (bmap=0x0) at ../isl-0.22/isl_map.c:5515 #1 0x77e56431 in isl_basic_map_is_empty (bmap=0x28185f0) at ../isl-0.22/isl_map.c:8988 #2 isl_basic_map_is_empty (bmap=0x28185f0) at ../isl-0.22/isl_map.c:8958 #3 0x77e578da in map_product (map1=0x27eb7b0, map2=0x27f4a90, space_product=, basic_map_product=0x77e4dfa0 , remove_duplicates=1) at ../isl-0.22/isl_map.c:10468 #4 0x77e2ede3 in coscheduled_source (acc=acc@entry=0x27f8c20, old_map=0x27f4a90, pos=pos@entry=8, depth=) at ../isl-0.22/isl_flow.c:941 #5 0x77e3115c in handle_coscheduled (flow=0x28455d0, may_rel=0x2845370, must_rel=0x2845330, acc=0x27f8c20) at ../isl-0.22/isl_flow.c:1034 #6 compute_val_based_dependences (acc=) at ../isl-0.22/isl_flow.c:1238 #7 access_info_compute_flow_core (acc=, acc@entry=0x27f8c20) at ../isl-0.22/isl_flow.c:1338 #8 0x77e326ac in compute_single_flow (data=0x7fffcfc0, sink=, uf=0x27d6410) at ../isl-0.22/isl_flow.c:3082 #9 compute_flow_schedule (access=0x28ab6e0) at ../isl-0.22/isl_flow.c:3166 #10 isl_union_access_info_compute_flow (access=0x28ab6e0) at ../isl-0.22/isl_flow.c:3217 #11 0x017b5b9e in scop_get_dependences(scop*) () #12 0x017b603b in apply_poly_transforms(scop*) () #13 0x017b02d2 in graphite_transform_loops() () #14 0x017b0809 in (anonymous namespace)::pass_graphite_transforms::execute(function*) () #15 0x00c0caed in execute_one_pass(opt_pass*) () #16 0x00c0d50f in execute_pass_list_1(opt_pass*) () #17 0x00c0d521 in execute_pass_list_1(opt_pass*) () #18 0x00c0d521 in execute_pass_list_1(opt_pass*) () #19 0x00c0d521 in execute_pass_list_1(opt_pass*) () #20 0x00c0d53a in execute_pass_list(function*, opt_pass*) () #21 0x0080d779 in cgraph_node::expand() () #22 0x0080f2c2 in symbol_table::compile() () #23 0x008117ba in symbol_table::finalize_compilation_unit() () #24 0x00cfab26 in compile_file() () #25 0x00cfd784 in toplev::main(int, char**) () #26 0x018f083c in main () (gdb) list 5510!isl_space_is_named_or_nested(bmap->dim, isl_dim_in) && 5511!isl_space_is_named_or_nested(bmap->dim, isl_dim_out)) 5512return bset_from_bmap(bmap); 5513bmap = isl_basic_map_cow(bmap); 5514space = isl_basic_map_take_space(bmap); 5515space = isl_space_underlying(space, bmap->n_div); 5516bmap = isl_basic_map_restore_space(bmap, space); 5517if (!bmap) 5518return NULL; 5519bmap->extra -= bmap->n_div; (gdb) print bmap $1 = (isl_basic_map *) 0x0
[Bug testsuite/93058] New: FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 Bug ID: 93058 Summary: FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors) Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Noticed asan test failure: $ make check-c++ -j9 RUNTESTFLAGS='asan.exp=asan_test.C' FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors) Executing on host: /home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../xg++ -B/home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g -I/home/slyfox/dev/git/gcc/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -I/home/slyfox/dev/git/gcc/libstdc++-v3/include/backward -I/home/slyfox/dev/git/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 -D__NO_INLINE__ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/ -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/.libs -lm -o ./asan_test.exe(timeout = 300) spawn -ignore SIGHUP /home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../xg++ -B/home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g -I/home/slyfox/dev/git/gcc/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -I/home/slyfox/dev/git/gcc/libstdc++-v3/include/backward -I/home/slyfox/dev/git/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 -D__NO_INLINE__ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/ -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/.libs -lm -o ./asan_test.exe In file included from /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.C:14: /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc: In function 'void AddressSanitizer_PvallocTest_fn()': /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:129:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:127:27: note: at offset 4197 to an object with size 4196 allocated by 'pvalloc' here /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:134:10: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:132:21: note: at offset 101 to an object with size 0 allocated by 'pvalloc' here cc1plus: all warnings being treated as errors compiler exited with status 1 Executing on
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058
--- Comment #1 from Sergei Trofimovich ---
Th important bits seems to be:
gcc/testsuite/g++.dg/asan/asan_test.cc:129:22: error: writing 1 byte into a
region of size 0 [-Werror=stringop-overflow=]
I think it happens because glibc marks pvalloc() as malloc()-like function.
Test explicitly assumes that granularity is page-wide:
char *a = (char*)pvalloc(kPageSize + 100);
EXPECT_EQ(0U, (uintptr_t)a % kPageSize);
/* 129 */ a[kPageSize + 101] = 1; // we should not report an error here.
free(a);
As build fails due to -Werror what would be a reasonable fix here?
I tested adding -Wno-stringop-overflow as and it seems to work:
$ git diff -U0 | cat
diff --git a/gcc/testsuite/g++.dg/asan/asan_test.C
b/gcc/testsuite/g++.dg/asan/asan_test.C
index f3f7626ef3b..8e18744c7c6 100644
--- a/gcc/testsuite/g++.dg/asan/asan_test.C
+++ b/gcc/testsuite/g++.dg/asan/asan_test.C
@@ -5 +5 @@
-// { dg-options "-std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -g
-DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0
-DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
+// { dg-options "-std=c++11 -fsanitize=address -fno-builtin -Wall -Werror
-Wno-stringop-overflow -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1
-DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
[Bug c/93108] New: mmix generates invalid assembly on newlib (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93108 Bug ID: 93108 Summary: mmix generates invalid assembly on newlib (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Created attachment 47572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47572&action=edit bug.c Attached example is a self-contained preprocessed version of newlib-3.1.0/newlib/libc/stdio/vfprintf.c The crash looks like that: $ ./xgcc -B. -fstack-protector-strong -ffunction-sections -c bug.c -o bug.o bug.c: Assembler messages: bug.c:3419: Error: internal error: fixup not contained within frag $ ./xgcc -B. -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: mmix Configured with: ../gcc/configure --target=mmix --prefix=/home/slyfox/dev/git/gcc-mmix/../gcc-mmix-installed --with-sysroot=/usr/mmix --disable-bootstrap --enable-languages=c --disable-nls --with-native-system-header-dir=/include CFLAGS=-O0 CXXFLAGS=-O0 Thread model: single Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20191230 (experimental) (GCC)
[Bug c/93108] mmix generates invalid assembly on newlib (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93108 --- Comment #1 from Sergei Trofimovich --- Created attachment 47573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47573&action=edit min-bug.c The bug initially discovered on gcc-9.2.0. creduce managed to shrink it down to min-bug.c. On it the error and generated file look like: $ ./xgcc -B. -fstack-protector-strong -c min-bug.c -o min-bug.o -save-temps min-bug.c: Assembler messages: min-bug.c:430: Error: internal error: fixup not contained within frag $ nl -ha min-bug.s 426 BZ $0,L:4 427 SLU $0,$2,32 428 SR $0,$0,32 429 CMP $0,$0,0 430 BZ $0,L:4 431 GETA $2,LC:0 432 STOU $2,h 433 L:4 IS @ 434 SUBU $0,$253,16 435 LDO $1,$0,0 436 LDO $0,__stack_chk_guard 437 CMP $0,$1,$0 438 BZ $0,L:28 439 PUSHJ $8,__stack_chk_fail 440 L:28IS @ 441 SET $0,$2 442 INCL $254,#190 443 LDO $253,$254,0 444 ADDU $254,$254,8 445 POP 1,0 446 .data ! mmixal:= 8H LOC 9B
[Bug c/93108] mmix generates invalid assembly on newlib (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93108 --- Comment #2 from Sergei Trofimovich --- Commenting out 'GETA $2,LC:0' makes assembler get past the error. 'LC:0' is defined in '.rodata'. If I change '.rodata' manually to '.text' assembler can assemble ELF file from modified source. I guess 'fixup not contained within frag' is an equivalent of 'relocation points outside current ELF section'.
[Bug target/93108] mmix generates invalid assembly on newlib (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93108 --- Comment #4 from Sergei Trofimovich --- Sounds good! Filed https://sourceware.org/PR25331 against binutils/gas.
[Bug ipa/93115] New: gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115 Bug ID: 93115 Summary: gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 47577 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47577&action=edit bug.cpp Original build failure found and diagnosed by Jan Ziak in https://bugs.gentoo.org/704252. There gcc-9.2.0 fails to link an LLVM library due to missing inline function definition. It looks like two main triggers are -fdevirtualize-speculatively and -fipa-cp-clone trick gcc into not emitting inline function body. And only presence of -fvisibility-inlines-hidden makes it noticeable. I've managed to reproduce it on gcc-master and on gcc-9.2.0: This works: $ g++-9.2.0 -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fPIC -shared -o libbug.so bug.cpp -DLIB_FILE $ g++-9.2.0 -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -o main bug.cpp -DMAIN_FILE -L. -lbug This fails: g++-9.2.0 -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden -fPIC -shared -o libbug.so bug.cpp -DLIB_FILE g++-9.2.0 -fPIC -O1 -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden -o main bug.cpp -DMAIN_FILE -L. -lbug /usr/bin/ld: /tmp/ccQYknNI.o: in function `p()': bug.cpp:(.text+0x25): undefined reference to `m::av() const' /usr/bin/ld: bug.cpp:(.text+0x4e): undefined reference to `m::av() const' collect2: error: ld returned 1 exit status Note: we build both library libbug.so and main executables to observe that main lacks definition of inlinable 'm::av()'.
[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115 Sergei Trofimovich changed: What|Removed |Added Target||x86_64-pc-linux-gnu CC||0xe2.0x9a.0x9b at gmail dot com, ||hubicka at gcc dot gnu.org --- Comment #1 from Sergei Trofimovich --- I've built gcc-master as: $ ./xg++ -v Using built-in specs. COLLECT_GCC=./xg++ Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-clean/../gcc-native-quick-installed --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20200101 (experimental) (GCC)
[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115 --- Comment #2 from Sergei Trofimovich --- bug.cpp is a trimmed down version of llvm-roc's codebase with creduce.
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 --- Comment #12 from Sergei Trofimovich --- I started looking at implementing full local cache in complement to global evicting 'struct alg_hash_entry x_alg_hash[NUM_ALG_HASH_ENTRIES];' cache. Noob question: which gcc's data structure should I use to implement a simple append-only hash set of POD-like 'struct alg_hash_entry' keyed by 'alg_hash_entry::t' as a hash? 'gcc/hash-set.h', 'gcc/hash-map.h'? Or they are both wrong? Looks like for hash-* ones I need to define a bunch of traits that define things like 'is_deleted'/'is_empty'. I'm not very clear what it actually means. Do I need to embed/wrap 'is_deleted' flag into alg_hash_entry to accomodate the requirement?
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 --- Comment #4 from Sergei Trofimovich --- (In reply to Martin Liška from comment #3) > @Sergei: Can you please send a patch for this? Sent as https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01642.html
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Sergei Trofimovich --- In https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01682.html Jakub pointed out that was a fixable glibc bug. I assume it was fixed in https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=768c83b7f60d82db6677e19dc51be9f341e0f3fc closing this bug as INVALID. Apologies for the noise.
[Bug lto/93609] New: gcc -flto -fno-comon places symbols into ".text" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93609
Bug ID: 93609
Summary: gcc -flto -fno-comon places symbols into ".text"
section
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
It's an upstream version of https://bugs.gentoo.org/708340 where libtool was
not able to detect symbol type based on gcc-nm output.
Here is the small reproducer:
// cat a.c
char nm_test_var;
void nm_test_func(void){}
$ gcc -c a.c -o a.o -fcommon -flto && gcc-nm a.o
T nm_test_func
C nm_test_var
T/C - good
$ gcc -c a.c -o a.o -fno-common -flto && gcc-nm a.o
T nm_test_func
T nm_test_var
T/C - bad
For comparison here is non-lto version:
$ gcc -c a.c -o a.o -fcommon && gcc-nm a.o
T nm_test_func
0001 C nm_test_var
T/C - good
$ gcc -c a.c -o a.o -fno-common && gcc-nm a.o
T nm_test_func
B nm_test_var
T/B - good
libtool only cares if a symbol is reportes as T or not:
http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n3999
lt_cv_sys_global_symbol_to_cdecl="sed -n"\
$lt_cdecl_hook\
" -e 's/^T .* \(.*\)$/extern int \1();/p'"\
" -e 's/^$symcode$symcode* .* \(.*\)$/extern char \1;/p'"
Is it fair to say that it's a gcc (or binutils?) bug?
Reproducing on gcc-9.2.0 and gcc-master.
$ LANG=C gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/dev/shm/portage/sys-devel/gcc-9.2.0-r3/work/gcc-9.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.2.0-r3 p4' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0-r3 p4)
[Bug lto/93609] gcc -flto -fno-comon places symbols into ".text" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93609 --- Comment #2 from Sergei Trofimovich --- (In reply to Martin Liška from comment #1) > Hello, it's a known and reported issue: > https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html > https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Aha, makes sense. A lot more complicated than I thought. Thank you!
[Bug middle-end/40718] Invalid code produced with -foptimize-sibling-calls
--- Comment #1 from slyfox at inbox dot ru 2009-08-22 12:09 --- I can confirm gcc-4.4.1 errors the same way. I think stdcall is offender: My sample is more complicated, but has the same features: stdcall+tailcall. Produces SIGSEGV for me https://bugs.gentoo.org/show_bug.cgi?id=282189 -- slyfox at inbox dot ru changed: What|Removed |Added CC||slyfox at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40718
[Bug target/40718] Invalid code produced with -foptimize-sibling-calls
--- Comment #5 from slyfox at inbox dot ru 2009-08-22 18:38 --- (In reply to comment #3) > Created an attachment (id=18413) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18413&action=view) [edit] > patch to fix the failure > > Sibcalls of any kind should be done through call-clobbered regs only. > > This patch fixes the testcase. > > Sergei, can you please test it if it fixes your original problem? > Sorry, it does not compile on gcc-4.4.1: build/genoutput /tmp/paludis/sys-devel-gcc-4.4.1-r1/work/gcc-4.4.1/gcc/config/i386/i386.md \ insn-conditions.md > tmp-output.c /tmp/paludis/sys-devel-gcc-4.4.1-r1/work/gcc-4.4.1/gcc/config/i386/i386.md:14984: wrong number of alternatives in operand 2 make[3]: *** [s-output] Error 1 make[3]: *** Waiting for unfinished jobs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40718
[Bug target/40718] Invalid code produced with -foptimize-sibling-calls
--- Comment #8 from slyfox at inbox dot ru 2009-08-23 11:12 ---
(In reply to comment #7)
> Subject: Bug 40718
>
> Author: uros
> Date: Sun Aug 23 09:46:00 2009
> New Revision: 151028
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151028
> Log:
> PR target/40718
> * config/i386/i386.c (*call_pop_1): Disable for sibling calls.
> (*sibcall_pop_1): New insn pattern.
>
> testsuite/ChangeLog:
>
> PR target/40718
> * gcc.target/i386/pr40718.c: New test.
>
>
> Added:
> trunk/gcc/testsuite/gcc.target/i386/pr40718.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/i386/i386.md
> trunk/gcc/testsuite/ChangeLog
>
This patch fixes for me Dmitry's sample, but does not fix mine. Still SIGSEGVs.
I've managed to
place whole testcase in one file:
$ g++ -O1 -foptimize-sibling-calls -m32 -DCALLTYPE="__attribute__((stdcall))"
main.cc -o show_the_bug
$ ./show_the_bug
Segmentation fault
$ cat main.cc
#define CALLTYPE __attribute__((stdcall))
struct Base {
virtual unsigned long CALLTYPE base_do1(unsigned long, unsigned long)
__attribute__((noinline))
{
return 4;
}
};
static Base bi;
Base * glo_ptr_to_base = &bi;
struct Stuff {
void CALLTYPE do_stuff(unsigned long param1, unsigned long param2)
__attribute__((noinline))
{
if (param1 == 0xFFFE)
{
return;
}
glo_ptr_to_base->base_do1(param1, param2);
}
};
int
main()
{
Stuff o;
o.do_stuff(1, 32);
return 0;
}
---
_ZN5Stuff8do_stuffEmm:
.LFB1:
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
pushl %ebp
.cfi_def_cfa_offset 8
movl%esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register 5
pushl %ebx
subl$4, %esp
movl12(%ebp), %eax
cmpl$-2, %eax
je .L5
.cfi_offset 3, -12
movlglo_ptr_to_base, %edx
movl%edx, 8(%ebp)
movl-4(%ebp), %ebx
leave
jmp *(%ebx)
.L5:
movl-4(%ebp), %ebx
leave
ret $12
.cfi_endproc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40718
[Bug target/40718] Invalid code produced with -foptimize-sibling-calls
--- Comment #16 from slyfox at inbox dot ru 2009-08-29 10:26 --- (In reply to comment #15) > Fixed everywhere. > Just tested on my sample (got this only revision from 4_4 branch and applied to gentoo gcc sources). All works as expected. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40718
[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48088 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #5 from Sergei Trofimovich --- Stumbled on this bug today. I tried to use it in more intricate way: -Wframe-larger-than=4096 -Werror=frame-larger-than=32768 which would only warn about any stack more than 4096+, but would fail on 32768+. Does it make sense to implement desired behaviour? I guess it's not many '>=number' style options in gcc.
