[Bug middle-end/96406] erroneous -Wstringop-overflow storing into a multidimensional char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406 --- Comment #6 from Bruce Fleming --- Yes - that seems to work. Once Fedora move to 11.x, then the fixes will be available so I don't need workaround?
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #10 from H.J. Lu --- (In reply to H.J. Lu from comment #8) > The original pr26324a.o debug info contains reference to xxx. But reference > to xxx has been removed by LTO. simple_object_copy_lto_debug_sections fails > to remove the un-referenced symbol, xxx, from symbol table. The alternative is to ask linker to handle it: https://sourceware.org/pipermail/binutils/2020-July/112673.html
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 H.J. Lu changed: What|Removed |Added Attachment #48956|0 |1 is obsolete|| --- Comment #9 from H.J. Lu --- Created attachment 48975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48975&action=edit A testcase [hjl@gnu-cfl-2 pr26324]$ make gcc -B./ -O2 -g -flto -ffat-lto-objects -c -o pr26324a.o pr26324a.c gcc -B./ -O2 -g -fPIC -c -o pr15146c.o pr15146c.c gcc -B./ -O2 -g -fPIC -c -o pr15146b.o pr15146b.c gcc -B./ -shared -o pr15146b.so pr15146b.o gcc -B./ -shared -o pr15146c.so pr15146c.o pr15146b.so gcc -B./ -O2 -g -o x -Wl,-R,. \ -Wl,--no-copy-dt-needed-entries -Wl,--no-as-needed pr26324a.o pr15146c.so ./ld: /tmp/ccCGQCqp.debug.temp.o: undefined reference to symbol 'xxx' ./ld: ./pr15146b.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [Makefile:20: x] Error 1 [hjl@gnu-cfl-2 pr26324]$ -flto -ffat-lto-objects is the key.
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #10 from David Edelsohn --- r11-2445 succeeds. I am testing r11-2447 and then r11-2451.
[Bug middle-end/96406] erroneous -Wstringop-overflow storing into a multidimensional char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406
--- Comment #5 from Martin Sebor ---
10.2 is the latest released version. GCC 11 is the development version. If
you normally don't build it from source they I suspect you won't have
convenient access to it.
Introducing a local variable and using it like below seems enough to change the
internal representation and fool the warning:
if((dev_length+1) < 32){
char *d = console_state.console_dev[(type-1)];
memcpy(d, &assign[1], dev_length);
d[dev_length] = '\0';
}
Does this help?
[Bug middle-end/96406] erroneous -Wstringop-overflow storing into a multidimensional char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406 Bruce Fleming changed: What|Removed |Added Version|10.1.1 |10.2.1 --- Comment #4 from Bruce Fleming --- Hi Martin, I incorrectly selected the wrong version when opening the bug. The version I am using is gcc version 10.2.1 20200723 (Fedora 32). Is this the latest?
[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 Tillmann Karras changed: What|Removed |Added CC||tilkax at gmail dot com --- Comment #5 from Tillmann Karras --- Ping. This warning is useful, but as was pointed out in comment #2, it currently triggers three times for each parameter.
[Bug middle-end/96406] erroneous -Wstringop-overflow storing into a multidimensional char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-07-31
Component|c |middle-end
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Summary|erroneous stringop-overflow |erroneous
|warnin |-Wstringop-overflow storing
||into a multidimensional
||char array
Status|UNCONFIRMED |WAITING
--- Comment #3 from Martin Sebor ---
I can reproduce the warning with the top of the GCC 10 branch (with the
attached translation unit as well as with the small test case below reduced
from it) but no longer with trunk, at least not on my machine or on
https://gcc.godbolt.org. I suspect it got fixed by
g:a2c2cee92e5defff9bf23d3b1184ee96e57e5fdd. The fix is somewhat intrusive so
I'm not 100% comfortable backporting it to GCC 10, but it's been on trunk for a
while so it might be safe by now.
If the warning is still reproducible on trunk it might be a duplicate of
pr96384 which also involves a multidimensional array. Can you retest with the
latest GCC?
$ cat pr96406.c && gcc -O2 -S -Wall -m32 pr96406.c
typedef struct console_info
{
char console_dev[3][32];
int console_owner;
} console_info_t;
static console_info_t console_state = {
.console_dev[1 -1] = { "/dev/ttyS1" },
.console_dev[2 -1] = { "/dev/ttyS1" },
.console_owner = 0
};
void console_param(int type, char *param, int len)
{
char *assign = __builtin_memchr(param, '=', len);
if(assign){
int dev_length = len-(&assign[1]-param);
if((dev_length+1) < 32){
__builtin_memcpy(console_state.console_dev[(type-1)], &assign[1],
dev_length);
console_state.console_dev[(type-1)][dev_length] = '\0';
}
}
}
pr96406.c: In function ‘console_param’:
pr96406.c:22:52: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
22 |console_state.console_dev[(type-1)][dev_length] = '\0';
|^~
pr96406.c:4:7: note: at offset 0 to object ‘console_dev’ with size 96 declared
here
4 | char console_dev[3][32];
| ^~~
[Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471 Etienne Pellegrini changed: What|Removed |Added CC||etienne.pellegrini at jpl dot nasa ||.gov --- Comment #4 from Etienne Pellegrini --- This bug is reconfirmed with gcc-10.2.0, using Vladimir Fuka's reproduction source file. $ gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3 Driving: gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../src/gcc-10.2.0/configure --prefix=/home/etiennes/.local/opt/gcc-10.2.0 --exec-prefix=/home/etiennes/.local Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/f951 allocate.f90 -quiet -dumpbase allocate.f90 -mtune=generic -march=x86-64 -auxbase allocate -g -gdwarf-3 -version -fcheck=all -fbacktrace -fintrinsic-modules-path /home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude -o /tmp/ccM11kGs.s GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o /tmp/ccm2HDAF.o /tmp/ccM11kGs.s GNU assembler version 2.25.1 (x86_64-redhat-linux) using BFD version version 2.25.1-32.base.el7_4.1 Reading specs from /home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/collect2 -plugin /home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so -plugin-opt=/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccpR7PBS.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /lib/../lib64/crt1.o /lib/../lib64/crti.o /home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtbegin.o -L/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0 -L/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../.. /tmp/ccm2HDAF.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtend.o /lib/../lib64/crtn.o COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' $ ./a.out Segmentation fault
[Bug c/96406] erroneous stringop-overflow warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406 --- Comment #2 from Bruce Fleming --- Created attachment 48974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48974&action=edit preprocessed file
[Bug c/96406] erroneous stringop-overflow warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406 --- Comment #1 from Bruce Fleming --- Created attachment 48973 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48973&action=edit preprocessed file
[Bug c/96406] New: erroneous stringop-overflow warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96406 Bug ID: 96406 Summary: erroneous stringop-overflow warnin Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruce.fleming at gmail dot com Target Milestone: --- Created attachment 48972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48972&action=edit Command line and complete compiler output The compiler generates a stringop-overflow because it believes there is region size of zero which is being written a signal character into a (embedded 2 dimensional) array. I've tried several different work arounds but doesn't seem to . I have included the compiler version/system/etc in gcc.txt and the complete command line and output in cmd.txt. The preprocessed files are also attached.
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #9 from Sergei Trofimovich --- valgrind says there is use of uninitialized variable: ==3676055== Conditional jump or move depends on uninitialised value(s) ==3676055==at 0xDBED3B: vt_find_locations() (var-tracking.c:7230) ==3676055==by 0xDBF2FB: variable_tracking_main_1() (var-tracking.c:10519) ==3676055==by 0xDBF49B: variable_tracking_main (var-tracking.c:10565) ==3676055==by 0xDBF49B: (anonymous namespace)::pass_variable_tracking::execute(function*) (var-tracking.c:10602) ==3676055==by 0xA71977: execute_one_pass(opt_pass*) (passes.c:2509) ==3676055==by 0xA7229F: execute_pass_list_1(opt_pass*) (passes.c:2597) ==3676055==by 0xA722B1: execute_pass_list_1(opt_pass*) (passes.c:2598) ==3676055==by 0xA722B1: execute_pass_list_1(opt_pass*) (passes.c:2598) ==3676055==by 0xA722D8: execute_pass_list(function*, opt_pass*) (passes.c:2608) ==3676055==by 0x748A1D: cgraph_node::expand() (cgraphunit.c:2301) ==3676055==by 0x749E85: expand_all_functions (cgraphunit.c:2472) ==3676055==by 0x749E85: symbol_table::compile() [clone .part.0] (cgraphunit.c:2835) ==3676055==by 0x74BF22: compile (cgraphunit.c:2748) ==3676055==by 0x74BF22: symbol_table::finalize_compilation_unit() (cgraphunit.c:3013) ==3676055==by 0xB35FF0: compile_file() (toplev.c:483) ==3676055==by 0x5ED309: do_compile (toplev.c:2331) ==3676055==by 0x5ED309: toplev::main(int, char**) (toplev.c:2470) ==3676055==by 0x5F0FFB: main (main.c:39) ==3676055== Uninitialised value was created by a heap allocation ==3676055==at 0x483779F: malloc (vg_replace_malloc.c:307) ==3676055==by 0x14EE80B: xmalloc (xmalloc.c:147) ==3676055==by 0x14911F9: sbitmap_alloc(unsigned int) (sbitmap.c:51) ==3676055==by 0xDBE6BA: vt_find_locations() (var-tracking.c:7097) ==3676055==by 0xDBF2FB: variable_tracking_main_1() (var-tracking.c:10519) ==3676055==by 0xDBF49B: variable_tracking_main (var-tracking.c:10565) ==3676055==by 0xDBF49B: (anonymous namespace)::pass_variable_tracking::execute(function*) (var-tracking.c:10602) ==3676055==by 0xA71977: execute_one_pass(opt_pass*) (passes.c:2509) ==3676055==by 0xA7229F: execute_pass_list_1(opt_pass*) (passes.c:2597) ==3676055==by 0xA722B1: execute_pass_list_1(opt_pass*) (passes.c:2598) ==3676055==by 0xA722B1: execute_pass_list_1(opt_pass*) (passes.c:2598) ==3676055==by 0xA722D8: execute_pass_list(function*, opt_pass*) (passes.c:2608) ==3676055==by 0x748A1D: cgraph_node::expand() (cgraphunit.c:2301) ==3676055==by 0x749E85: expand_all_functions (cgraphunit.c:2472) ==3676055==by 0x749E85: symbol_table::compile() [clone .part.0] (cgraphunit.c:2835) ==3676055==by 0x74BF22: compile (cgraphunit.c:2748) ==3676055==by 0x74BF22: symbol_table::finalize_compilation_unit() (cgraphunit.c:3013) ==3676055==by 0xB35FF0: compile_file() (toplev.c:483) ==3676055==by 0x5ED309: do_compile (toplev.c:2331) ==3676055==by 0x5ED309: toplev::main(int, char**) (toplev.c:2470) ==3676055==by 0x5F0FFB: main (main.c:39)
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #8 from Sergei Trofimovich --- Created attachment 48971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48971&action=edit task.S-stage2-stage3.tar.gz
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #7 from David Edelsohn --- Created attachment 48970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48970&action=edit stage3 dbgcnt.s
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #6 from David Edelsohn --- Created attachment 48969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48969&action=edit stage2 dbgcnt.s
[Bug bootstrap/96404] [10 Regression] Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #5 from Sergei Trofimovich --- Comparing example file: $ LANG=C cmp --ignore-initial=16 ./stage2-x86_64-pc-linux-gnu/libgomp/task.o ./stage3-x86_64-pc-linux-gnu/libgomp/task.o ./stage2-x86_64-pc-linux-gnu/libgomp/task.o ./stage3-x86_64-pc-linux-gnu/libgomp/task.o differ: char 325521, line 4234 Looks like there is slight non-determinism in .debug_loc. Don't know if it comes from gcc or binutils. Both wibbly entries are the same symbol offset: $ diff -U1 <(x86_64-pc-linux-gnu-readelf -a stage2-x86_64-pc-linux-gnu/libgomp/task.o) <(x86_64-pc-linux-gnu-readelf -a stage3-x86_64-pc-linux-gnu/libgomp/task.o) | egrep 'section|^[-+]' Relocation section '.rela.debug_loc' at offset 0x36938 contains 7185 entries: -e312 00020001 R_X86_64_64 .text + 66b8 -e320 00020001 R_X86_64_64 .text + 66b8 +e312 00020001 R_X86_64_64 .text + 66cd +e320 00020001 R_X86_64_64 .text + 66cd -e6f5 00020001 R_X86_64_64 .text + 66b8 -e703 00020001 R_X86_64_64 .text + 66b8 +e6f5 00020001 R_X86_64_64 .text + 66cd +e703 00020001 R_X86_64_64 .text + 66cd -e9c4 00020001 R_X86_64_64 .text + 66b8 -e9d2 00020001 R_X86_64_64 .text + 66b8 +e9c4 00020001 R_X86_64_64 .text + 66cd +e9d2 00020001 R_X86_64_64 .text + 66cd -ec69 00020001 R_X86_64_64 .text + 66b8 +ec69 00020001 R_X86_64_64 .text + 66cd -eecd 00020001 R_X86_64_64 .text + 66b8 +eecd 00020001 R_X86_64_64 .text + 66cd -ef61 00020001 R_X86_64_64 .text + 66b8 +ef61 00020001 R_X86_64_64 .text + 66cd -f01f 00020001 R_X86_64_64 .text + 66b8 +f01f 00020001 R_X86_64_64 .text + 66cd -f388 00020001 R_X86_64_64 .text + 66b8 +f388 00020001 R_X86_64_64 .text + 66cd -000112e3 00020001 R_X86_64_64 .text + 5a84 +000112e3 00020001 R_X86_64_64 .text + 5a79
[Bug c++/96182] GCC accepts constexpr function with no return-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96182 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5f9669d9e23a1116e040c80e0f3d4f43639bda52 commit r11-2473-g5f9669d9e23a1116e040c80e0f3d4f43639bda52 Author: Jakub Jelinek Date: Fri Jul 31 23:08:00 2020 +0200 c++: Use error_at rather than warning_at for missing return in constexpr functions [PR96182] For C++11 we already emit an error if a constexpr function doesn't contain a return statement, because in C++11 that is the only thing it needs to contain, but for C++14 we would normally issue a -Wreturn-type warning. As mentioned by Jonathan, such constexpr functions are invalid, no diagnostics required, because there doesn't exist any arguments for which it would result in valid constant expression. This raises it to an error in such cases. The !LAMBDA_TYPE_P case is to avoid error on g++.dg/pr81194.C where the user didn't write constexpr anywhere and the operator() is compiler generated. 2020-07-31 Jakub Jelinek PR c++/96182 * decl.c (finish_function): In constexpr functions use for C++14 and later error instead of warning if no return statement is present and diagnose it regardless of warn_return_type. Move the warn_return_type diagnostics earlier in the function. * g++.dg/cpp1y/constexpr-96182.C: New test. * g++.dg/other/error35.C (S::g()): Add return statement. * g++.dg/cpp1y/pr63996.C (foo): Likewise. * g++.dg/cpp1y/constexpr-return2.C (f): Likewise. * g++.dg/cpp1y/var-templ44.C (make_array): Add throw 1.
[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target|powerpc-ibm-aix*|*-*-* Last reconfirmed||2020-07-31 --- Comment #4 from David Edelsohn --- This seems to be present for x86_64-*-linux also. I reverted the debug change, but the failure still is present. Continuing to search for the offending patch.
[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #3 from David Edelsohn --- This apparently occurs on x86_64-*-linux, so this is a more general problem. It does not appear to be due to the debug patch.
[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 --- Comment #2 from Sergei Trofimovich --- Seeing this as well on amd64-linux: $ LANG=C ./xgcc -B. -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /tmp/portage-tmpdir/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python --enable-languages=c,c++,go,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 11.0.0_pre p2, commit 8011f718e241febd6b7a9dae01cde49817f299c4' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-valgrind-annotations --enable-vtable-verify --without-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20200731 (experimental) (Gentoo 11.0.0_pre p2, commit 8011f718e241febd6b7a9dae01cde49817f299c4)
[Bug debug/96405] Comparing stages 2 and 3: Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96405 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Sergei Trofimovich --- Marking as duplicate of bug #96404 *** This bug has been marked as a duplicate of bug 96404 ***
[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #1 from Sergei Trofimovich --- *** Bug 96405 has been marked as a duplicate of this bug. ***
[Bug debug/96405] Comparing stages 2 and 3: Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96405 --- Comment #1 from Sergei Trofimovich --- $ LANG=C ./xgcc -B. -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /tmp/portage-tmpdir/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python --enable-languages=c,c++,go,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 11.0.0_pre p2, commit 8011f718e241febd6b7a9dae01cde49817f299c4' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-valgrind-annotations --enable-vtable-verify --without-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20200731 (experimental) (Gentoo 11.0.0_pre p2, commit 8011f718e241febd6b7a9dae01cde49817f299c4)
[Bug debug/96405] New: Comparing stages 2 and 3: Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96405 Bug ID: 96405 Summary: Comparing stages 2 and 3: Bootstrap comparison failure! Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org CC: rguenther at suse dot de Target Milestone: --- Today's gcc master at: """ commit f07fa7a31c89811ad9ffdd9831177cc815f098d2 Author: Jonathan Wakely Date: Fri Jul 31 19:58:03 2020 +0100 libstdc++: Fix test that fails for C++98 """ fails bootstrap as: Comparing stages 2 and 3 Bootstrap comparison failure! gcc/gcc.o differs gcc/gengtype-state.o differs gcc/gengtype.o differs gcc/lto-wrapper.o differs gcc/collect2.o differs gcc/gcov.o differs gcc/pretty-print.o differs gcc/diagnostic-show-locus.o differs ... Unverified guess is https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c6ef9d8d3f11221df1ea635
[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Investigating.
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #8 from H.J. Lu --- The original pr26324a.o debug info contains reference to xxx. But reference to xxx has been removed by LTO. simple_object_copy_lto_debug_sections fails to remove the un-referenced symbol, xxx, from symbol table.
[Bug libstdc++/96382] [11 Regression] const_reverse_iterator() ctor is rejected in c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96382 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed
[Bug libstdc++/96382] [11 Regression] const_reverse_iterator() ctor is rejected in c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96382 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8abab28bb5c0cd80063518d47494cb6078767b89 commit r11-2465-g8abab28bb5c0cd80063518d47494cb6078767b89 Author: Jonathan Wakely Date: Fri Jul 31 19:55:28 2020 +0100 libstdc++: Remove condition around friend declaration (PR 96382) libstdc++-v3/ChangeLog: PR libstdc++/96382 * include/bits/stl_iterator.h (reverse_iterator): Friend declaration should not depend on __cplusplus.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #4 from Michael Cronenworth --- The preprocessed file, even XZ compressed, is too large for attaching here. https://github.com/mooninite/gcc-bug/blob/master/Unified_cpp_widget_windows0.ii.xz
[Bug analyzer/96395] gcc.dg/analyzer/explode-2.c fails when compiled as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Once my C/C++ loop unification changes are in, this test case will fail when compiled as C, too. Recording that it fails as C++ already gives you a way to duplicate the bug meanwhile, independently of my patches, and also gives me an issue to track the future C testsuite regression introduced by my patches. It seems like it would be a good idea generally to run analyzer unit tests as both C and C++, though. This is a pretty simple test case, and yet the analyzer completely falls over on it, which doesn't fill me with confidence on how well it would work on any real C++ program, even one that doesn't use templates or exceptions.
[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 David Edelsohn changed: What|Removed |Added Blocks||96383 Target||powerpc-ibm-aix* Severity|normal |blocker CC||rguenth at gcc dot gnu.org Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 [Bug 96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C
[Bug bootstrap/96404] New: [10 Regression] AIX Bootstrap failure with DWARF debug changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404 Bug ID: 96404 Summary: [10 Regression] AIX Bootstrap failure with DWARF debug changes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- After the patch for debug/96383, bootstrap fails on AIX due to stage2/stage3 comparison failure. The DWARF debugging information differs.
[Bug target/90928] [9/10/11 Regression] [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928 --- Comment #5 from CVS Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:3a4a92598014d33ef2c8b8ec38d8ad917812921a commit r11-2464-g3a4a92598014d33ef2c8b8ec38d8ad917812921a Author: Roger Sayle Date: Thu Jul 30 11:42:06 2020 +0200 nvptx: Define TARGET_TRULY_NOOP_TRUNCATION to false Many thanks to Richard Biener for approving the midde-end patch that cleared the way for this one. This nvptx patch defines the target hook TARGET_TRULY_NOOP_TRUNCATION to false, indicating that integer truncations require explicit instructions. nvptx.c already defines TARGET_MODES_TIEABLE_P and TARGET_CAN_CHANGE_MODE_CLASS to false, and as (previously) documented that may require TARGET_TRULY_NOOP_TRUNCATION to be defined likewise. This patch decreases the number of unexpected failures in the testsuite by 10, and increases the number of expected passes by 4, including these previous FAILs/ICEs: gcc.c-torture/compile/opout.c gcc.dg/torture/pr79125.c gcc.dg/tree-ssa/pr92085-1.c Unfortunately there is one testsuite failure that used to pass gcc.target/nvptx/v2si-cvt.c, but this isn't an ICE or incorrect code. This regression has been filed as PR96403, and the failing scan-assembler directives have been replaced by a reference to the PR. This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu with "make" and "make check" with fewer ICEs and no wrong code regressions. 2020-07-31 Roger Sayle Tom de Vries gcc/ChangeLog: PR target/90928 * config/nvptx/nvptx.c (nvptx_truly_noop_truncation): Implement. (TARGET_TRULY_NOOP_TRUNCATION): Define. gcc/testsuite/ChangeLog: * gcc.target/nvptx/v2si-cvt.c: Simplify source. Remove scan-assembler directives. Mention PR96403.
[Bug target/96403] [nvptx] Less optimal code in v2si-cvt.c after setting TARGET_TRULY_NOOP_TRUNCATION to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96403
Tom de Vries changed:
What|Removed |Added
Target||nvptx
--- Comment #1 from Tom de Vries ---
Looking at the first regression, we have without the patch:
...
//(insn 9 5 12 2
//(set (reg:HI 27 [ arg ])
// (subreg:HI (reg/v:V2SI 25 [ arg ]) 0))
// "v2si-cvt.c":11:32 5 {*movhi_insn}
// (nil))
cvt.u16.u32 %r27, %r25.x; // 9 [c=12] *movhi_insn/0
...
and with the patch:
...
//(insn 8 5 9 2
//(set (reg:DI 26 [ arg ])
// (subreg:DI (reg/v:V2SI 25 [ arg ]) 0))
// "v2si-cvt.c":11:32 7 {*movdi_insn}
// (nil))
mov.b64 %r26, %r25; // 8[c=12] *movdi_insn/0
//(insn 9 8 13 2
//(set (reg:HI 27 [ arg ])
// (truncate:HI (reg:DI 26 [ arg ])))
// "v2si-cvt.c":11:32 32 {truncdihi2}
// (expr_list:REG_DEAD (reg:DI 26 [ arg ])
//(nil)))
cvt.u16.u64 %r27, %r26;
...
I guess we would like to generate this instead:
...
//(insn 9 8 13 2
//(set (reg:HI 27 [ arg ])
// (truncate:HI (subreg:SI (reg/v:V2SI 25 [ arg ]) 0))
// "v2si-cvt.c":11:32 32 {truncdihi2}
// (expr_list:REG_DEAD (reg:DI 26 [ arg ])
//(nil)))
cvt.u16.u32 %r26, %r25.x;
...
Debugging combine, we hit TARGET_MODES_TIEABLE_P as a barrier, but after
enabling that we have a slightly different inns (the store has merged with the
truncate), where combine also fails:
...
Trying 8 -> 13:
8: r26:DI=r25:V2SI#0
13: [%frame:DI]=trunc(r26:DI)
REG_DEAD r26:DI
Failed to match this instruction:
(set (mem/v/c:HI (reg/f:DI 2 %frame) [2 s+0 S2 A128])
(truncate:HI (subreg:DI (reg/v:V2SI 25 [ arg ]) 0)))
...
I've tried enabling subregs in truncsi but that didn't help either.
I managed to get the desired code using this (to match the pattern tried by
combine):
...
@@ -372,11 +386,26 @@
(define_insn "truncdi2"
[(set (match_operand:QHSIM 0 "nvptx_nonimmediate_operand" "=R,m")
- (truncate:QHSIM (match_operand:DI 1 "nvptx_register_operand" "R,R")))]
+ (truncate:QHSIM (match_operand:DI 1 "register_operand" "R,Q")))]
""
- "@
- %.\\tcvt%t0.u64\\t%0, %1;
- %.\\tst%A0.u%T0\\t%0, %1;"
+{
+if (which_alternative == 0)
+ {
+if (SUBREG_P (operands[1])
+ && GET_MODE (SUBREG_REG (operands[1])) == V2SImode)
+ return "%.\\tcvt%t0.u32\\t%0, %1.x;";
+else
+ return "%.\\tcvt%t0.u64\\t%0, %1;";
+ }
+else
+ {
+if (SUBREG_P (operands[1])
+ && GET_MODE (SUBREG_REG (operands[1])) == V2SImode)
+ return " %.\\tst%A0.u%T0\\t%0, %1.x;";
+else
+ return " %.\\tst%A0.u%T0\\t%0, %1;";
+ }
+}
[(set_attr "subregs_ok" "true")])
;; Integer arithmetic
...
But I would hope there's a cleaner way.
[Bug target/96403] New: [nvptx] Less optimal code in v2si-cvt.c after setting TARGET_TRULY_NOOP_TRUNCATION to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96403
Bug ID: 96403
Summary: [nvptx] Less optimal code in v2si-cvt.c after setting
TARGET_TRULY_NOOP_TRUNCATION to false
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ I've rewritten the v2si-cvt.c source to something more minimal:
...
__v2si __attribute__((unused))
vector_cvt (__v2si arg)
{
unsigned short *p = (unsigned short*)&arg;
volatile unsigned short s = p[0];
return arg;
}
__v2si __attribute__((unused))
vector_cvt_2 (__v2si arg)
{
unsigned char *p = (unsigned char*)&arg;
volatile unsigned char s = p[0];
return arg;
}
...
]
When changing TARGET_TRULY_NOOP_TRUNCATION to false, we have a regression in
v2si-cvt.c, this for vector_cvt:
...
- cvt.u16.u32 %r27, %r25.x;
+ mov.b64 %r26, %r25;
+ cvt.u16.u64 %r27, %r26;
...
and this for vector_cvt_2:
...
- cvt.u32.u32 %r27, %r25.x;
- st.u8 [%frame], %r27;
+ mov.b64 %r26, %r25;
+ cvt.u32.u64 %r27, %r26;
+ cvt.u16.u8 %r32, %r27;
+ mov.u16 %r29, %r32;
+ cvt.u32.u16 %r30, %r29;
+ st.u8 [%frame], %r30;
...
[Bug d/96393] [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fixed.
[Bug d/96393] [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393 --- Comment #4 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:239724956d4ef29dcaa7f1b378cc76f5f6a7ad5b commit r11-2458-g239724956d4ef29dcaa7f1b378cc76f5f6a7ad5b Author: Iain Buclaw Date: Fri Jul 31 16:03:17 2020 +0200 d: Fix regression, all 32-bit execution tests FAIL: internal error printing module cycle For 32-bit btr(), BIT_NOT_EXPR was being generated twice, something that was not seen with the 64-bit variant. Removed the second call to fix the generated code. gcc/d/ChangeLog: PR d/96393 * intrinsics.cc (expand_intrinsic_bt): Don't generate BIT_NOT_EXPR for btr32 intrinsic.
[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 --- Comment #18 from Martin Sebor --- (In reply to Sergei Trofimovich from comment #8) > Also, the "'this' pointer null" error wording is not very clear. Should it > be "'this' pointer is null"? Or "'this' pointer may be null"? I agree that the text doesn't read quite right. It's just a slight rewording of the generic "argument 1 null..." so both might read better if rephrased as you suggest.
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Bug 95507 depends on bug 96003, which changed state. Bug 96003 Summary: [11 Regression] spurious -Wnonnull calling a member on the result of static_cast https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED|RESOLVED
--- Comment #17 from Martin Sebor ---
Warnings for the static cast suppressed in r11-2457.
The warning for the dynamic cast is still issued and I would suggest to use a
cast to a reference instead, both to avoid it and as an indication that the
cast is expected to succeed (or throw):
if (mainloop_ && typeid(mainloop_) == typeid(M)) {
dynamic_cast(*mainloop_).setup_M( );
[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 --- Comment #16 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:df5cf47a978aaeb53fc2b18ff0b22eb4531a27d8 commit r11-2457-gdf5cf47a978aaeb53fc2b18ff0b22eb4531a27d8 Author: Martin Sebor Date: Fri Jul 31 10:27:33 2020 -0600 Set and test no-warning bit to avoid -Wnonnull for synthesized expressions. Resolves: PR c++/96003 spurious -Wnonnull calling a member on the result of static_cast gcc/c-family/ChangeLog: PR c++/96003 * c-common.c (check_function_arguments_recurse): Return early when no-warning bit is set. gcc/cp/ChangeLog: PR c++/96003 * class.c (build_base_path): Set no-warning bit on the synthesized conditional expression in static_cast. gcc/testsuite/ChangeLog: PR c++/96003 * g++.dg/warn/Wnonnull7.C: New test.
[Bug d/96154] d: Add -Wvarargs warning flag to compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96154 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Done.
[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402 --- Comment #3 from ktkachov at gcc dot gnu.org --- Thanks, that's a CPU without the LSE instructions so it should be using the load-exclusive-store-exclusive loop fallback
[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402 --- Comment #2 from Martin Liška --- (In reply to ktkachov from comment #1) > Thanks, can you share the hardware you ran it on? Depending on whether LSE > is present different code paths are taken at runtime... Well, I tested that on an experimental hardware we were given by AMD. cpuinfo says something like: processor : 6 BogoMIPS: 500.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part: 0xd07 CPU revision: 2
[Bug ada/96344] 3rdd case of gnat.dg/opt86a.adb fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344
Eric Botcazou changed:
What|Removed |Added
Summary|[11 regerssion] |3rdd case of
|gnat.dg/opt86a.adb fails|gnat.dg/opt86a.adb fails
|starting with r11-1675 |
Target Milestone|11.0|---
Last reconfirmed||2020-07-31
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Eric Botcazou ---
I can reproduce: the third optimization does not work
[local count: 1070914630]:
if (_40 == 1)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 1070486265]:
_65 = s3_41 + 252;
_73 = _65 & 251;
if (_73 == 0)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 1284581]:
.gnat_rcheck_PE_Explicit_Raise ("opt86a.adb", 27);
but that's not a regression, just a missed optimization.
[Bug target/96375] [11 regression] arm/lob[2-5].c fail on some configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375 --- Comment #1 from akrl at gcc dot gnu.org --- Created attachment 48968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48968&action=edit pr96375 lob tests patch Hi Christophe, The following patch does the job for me. Would you double check is effective for you too? Thanks Andrea
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385
--- Comment #7 from H.J. Lu ---
[hjl@gnu-cfl-2 pr26324]$ cat pr15146a.c
extern int xxx;
int
bar (void)
{
return xxx;
}
int
main ()
{
return 0;
}
[hjl@gnu-cfl-2 pr26324]$ cat pr15146b.c
int xxx = 3;
[hjl@gnu-cfl-2 pr26324]$ cat pr15146c.c
[hjl@gnu-cfl-2 pr26324]$ make
gcc -B./ -O2 -g -o x -Wl,-R,. \
-Wl,--no-copy-dt-needed-entries -Wl,--no-as-needed pr15146a.o pr15146c.so
./ld: /tmp/ccHirkTe.debug.temp.o: undefined reference to symbol 'xxx'
./ld: ./pr15146b.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:15: x] Error 1
[hjl@gnu-cfl-2 pr26324]$
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 H.J. Lu changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26324 --- Comment #6 from H.J. Lu --- There is a small testcase in https://sourceware.org/bugzilla/show_bug.cgi?id=26324
[Bug middle-end/96390] [OpenMP] Link errors on the offload side for C++ code with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390
--- Comment #3 from Tobias Burnus ---
The following helps with the "S<0>::S()" problem – but then one runs into the
"V<1>::V" problem.
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -207,6 +207,12 @@ omp_discover_declare_target_tgt_fn_r (tree *tp, int
symtab_node *node = symtab_node::get (*tp);
if (node != NULL)
{
+ if (node->cpp_implicit_alias)
+ {
+ node = node->get_alias_target ();
+ DECL_ATTRIBUTES (node->decl)
+ = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (node->decl));
+ }
node->offloadable = 1;
if (ENABLE_OFFLOADING)
g->have_offload = true;
[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402 --- Comment #1 from ktkachov at gcc dot gnu.org --- Thanks, can you share the hardware you ran it on? Depending on whether LSE is present different code paths are taken at runtime...
[Bug target/96401] [nvptx] Take advantage of subword ld/st/cvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
--- Comment #3 from Tom de Vries ---
Note that with the proposed TARGET_TRULY_NOOP_TRUNCATION -> false change (
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549896.html ), we start out
with the same ptx insns, but with the cvt.u16.u32 a truncate instead of a
subreg move:
...
//(insn 5 2 6 2
//(set (reg:SI 22 [ v$0_1 ])
// (mem/v/c:SI (reg/f:DI 2 %frame) [1 v+0 S4 A128]))
// "test.c":7:6 6 {*movsi_insn}
// (nil))
ld.u32 %r22, [%frame]; // 5[c=4] *movsi_insn/1
//(insn 6 5 9 2
//(set (reg:HI 24 [ v$0_1 ])
// (truncate:HI (reg:SI 22 [ v$0_1 ])))
"test.c":7:6 30 {truncsihi2}
// (expr_list:REG_DEAD (reg:SI 22 [ v$0_1 ])
// (nil)))
cvt.u16.u32 %r24, %r22; // 6[c=4] truncsihi2/0
//(insn 9 6 12 2
//(set (mem/v/c:HI (plus:DI (reg/f:DI 2 %frame)
// (const_int 4 [0x4])) [2 v2+0 S2 A32])
// (reg:HI 24 [ v$0_1 ])) "test.c":7:6 5 {*movhi_insn}
// (expr_list:REG_DEAD (reg:HI 24 [ v$0_1 ])
//(nil)))
st.u16 [%frame+4], %r24; // 9[c=4] *movhi_insn/2
...
Still, with the changes in comment 1 enabled we end up with the desired two
insns, though a bit later, at cse2 (265r), and not using movhi_insn:
...
(insn 9 5 0 2 (set (mem/v/c:HI (plus:DI (reg/f:DI 2 %frame)
(const_int 4 [0x4])) [2 v2+0 S2 A32])
(truncate:HI (reg:SI 22 [ v$0_1 ]))) "test.c":7:6 30 {truncsihi2}
(expr_list:REG_DEAD (reg:HI 24 [ v$0_1 ])
(nil)))
...
so we might get this just with the nvptx_modes_tieable_p change.
[Bug target/96402] New: [10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402
Bug ID: 96402
Summary: [10/11 Regression] Wrong code with -moutline-atomics
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rth at gcc dot gnu.org
Target Milestone: ---
Host: aarch64-linux-gnu
The following is miscompiled:
$ cat x.c
#include
int main(void) {
__int128 a = 0;
__sync_val_compare_and_swap(&a, 0, 1);
printf("a:%d\n", (int)a);
if (a == 0)
__builtin_abort ();
return 0;
}
$ gcc x.c -moutline-atomics && ./a.out
a:0
Aborted (core dumped)
$ gcc x.c -mno-outline-atomics && ./a.out
a:1
[Bug tree-optimization/96397] GCC Fails to exploit ranges from overflow tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397 --- Comment #2 from Andrew Macleod --- if I read this right, the basic premise is: x = p1 - 4, so if x + 8 doesn't overflow, then p1 - 4 couldn't have underflowed, and therefore x must be > p1 which is a little more complicated than just back propagation. Firstly, we have to understand that builtin_add_overflow is actually x + 8 and that the IMAG_PART is in fact the overflow flag. we currently understand that the IMAG_PART is a boolean, but we dont "understand" the add yet. so we'll eventually start treating those built-ins like tree-codes and provide the appropriate understanding. secondly, the x = p1 - 4 + 8 calculation is handle-able by rangeops, we just need slightly better range tracking of overflows on unsigned values.. which is already on my todo list. and then the if (x > p1) would be handled by the upcoming relational code automatically once we get the calculation right. so its not quite as simple as back propagation, but it is on the radar, possibly during this stage 1.
[Bug target/96401] [nvptx] Take advantage of subword ld/st/cvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Using these changes, I get the desired:
> ...
> .reg.u32 %r22;
> ld.u32 %r22, [%frame];
> st.u16 [%frame+4], %r22;
> ...
And to be precise about it, that's starting at fwprop1 that we have two insns:
...
(insn 5 2 9 2
(set (reg:SI 22 [ v$0_1 ])
(mem/v/c:SI (reg/f:DI 2 %frame) [1 v+0 S4 A128]))
"test.c":7:6 6 {*movsi_insn}
(nil))
(insn 9 5 0 2
(set (mem/v/c:HI (plus:DI (reg/f:DI 2 %frame)
(const_int 4 [0x4])) [2 v2+0 S2 A32])
(subreg:HI (reg:SI 22 [ v$0_1 ]) 0))
"test.c":7:6 5 {*movhi_insn}
(expr_list:REG_DEAD (reg:SI 23 [ _2 ])
(nil)))
...
Which is a bit earlier (at 247r) than combine (at 271r).
[Bug analyzer/96395] gcc.dg/analyzer/explode-2.c fails when compiled as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 --- Comment #1 from David Malcolm --- Thanks for filing this. FWIW I've spent the last 4 months rewriting the state-tracking heart of the analyzer, with a patch kit I hope to land next month. Along with many other changes, explode-2.c changes behavior significantly in my new implementation. It sounds like we might have to coordinate on how we get our changes into trunk. I believe that that test case currently isn't compiled with g++. Are you changing that? Feel free to special-case it if need be if you need that to get your changes in.
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 --- Comment #8 from Patrick Palka --- Fixed for GCC 11 so far, PR remains open to consider backporting the fix to the 10 branch after a while.
[Bug target/96401] [nvptx] Take advantage of subword ld/st/cvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> In other words, we may emit instead:
> ...
> .reg.u32 %r22;
> ld.u32 %r22, [%frame];
> st.u16 [%frame+4], %r22;
> ...
So, why don't we?
Using -dP we see the respective insns:
...
//(insn 5 2 6 2
//(set (reg:SI 22 [ v$0_1 ])
// (mem/v/c:SI (reg/f:DI 2 %frame) [1 v+0 S4 A128]))
// "test.c":7:6 6 {*movsi_insn}
// (nil))
ld.u32 %r22, [%frame]; // 5[c=4] *movsi_insn/1
//(insn 6 5 9 2
//(set (reg:HI 24 [ v$0_1 ])
// (subreg:HI (reg:SI 22 [ v$0_1 ]) 0))
// "test.c":7:6 5 {*movhi_insn}
// (expr_list:REG_DEAD (reg:SI 22 [ v$0_1 ])
// (nil)))
cvt.u16.u32 %r24, %r22; // 6[c=12] *movhi_insn/0
//(insn 9 6 12 2
//(set (mem/v/c:HI (plus:DI (reg/f:DI 2 %frame)
// (const_int 4 [0x4])) [2 v2+0 S2 A32])
// (reg:HI 24 [ v$0_1 ]))
// "test.c":7:6 5 {*movhi_insn}
// (expr_list:REG_DEAD (reg:HI 24 [ v$0_1 ])
// (nil)))
st.u16 [%frame+4], %r24; // 9[c=4] *movhi_insn/2
...
I went to investigate why combine doesn't combine insns 6 and 9, that is, why
doesn't it generate:
...
//(insn 9 6 12 2
//(set (mem/v/c:HI (plus:DI (reg/f:DI 2 %frame)
// (const_int 4 [0x4])) [2 v2+0 S2 A32])
// (subreg:HI (reg:SI 22 [ v$0_1 ]) 0))
// "test.c":7:6 5 {*movhi_insn}
// (expr_list:REG_DEAD (reg:HI 22 [ v$0_1 ])
// (nil)))
...
Part of the required changes is to make the movhi_insn store alternative work
for subreg source operand:
...
@@ -229,8 +234,8 @@
(define_insn "*mov_insn"
[(set (match_operand:QHSDIM 0 "nonimmediate_operand" "=R,R,m")
- (match_operand:QHSDIM 1 "general_operand" "Ri,m,R"))]
- "!MEM_P (operands[0]) || REG_P (operands[1])"
+ (match_operand:QHSDIM 1 "general_operand" "Ri,m,Q"))]
+ "!MEM_P (operands[0]) || REG_P (operands[1]) || SUBREG_P (operands[1])"
{
if (which_alternative == 1)
return "%.\\tld%A1%u1\\t%0, %1;";
...
which required me to define:
...
+(define_constraint "Q"
+ "A pseudo register or subreg."
+ (ior (match_code "reg")
+ (match_code "subreg")))
+
...
[ Note that this constraint is an oddity, like the R constraint: it's not a
register constraint. ]
After debugging I found that I needed this as well:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index d2f321fcbcc..2234edad53b 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -6444,7 +6444,7 @@ nvptx_data_alignment (const_tree type, unsigned int
basic_align)
static bool
nvptx_modes_tieable_p (machine_mode, machine_mode)
{
- return false;
+ return true;
}
/* Implement TARGET_HARD_REGNO_NREGS. */
...
due to this bit in combine.c:subst():
...
/* In general, don't install a subreg involving two
modes not tieable. It can worsen register
allocation, and can even make invalid reload
insns, since the reg inside may need to be copied
from in the outside mode, and that may be invalid
if it is an fp reg copied in integer mode.
...
Using these changes, I get the desired:
...
.reg.u32 %r22;
ld.u32 %r22, [%frame];
st.u16 [%frame+4], %r22;
...
[Bug target/96401] New: [nvptx] Take advantage of subword ld/st/cvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
Bug ID: 96401
Summary: [nvptx] Take advantage of subword ld/st/cvt
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case test.c:
...
void
foo (void)
{
volatile unsigned int v;
volatile unsigned short v2;
v2 = v;
}
...
With the current compiler, we have:
...
$ gcc test.c -S -o- -O2
...
.reg.u32 %r22;
.reg.u16 %r24;
ld.u32 %r22, [%frame];
cvt.u16.u32 %r24, %r22;
st.u16 [%frame+4], %r24;
}
...
As it happens, the nvptx manual states at 5.2.2 "Restricted Use of Sub-Word
Sizes":
...
For convenience, ld, st, and cvt instructions permit source and destination
data operands to be wider than the instruction-type size, so that narrow values
may be loaded, stored, and converted using regular-width registers. For
example, 8-bit or 16-bit values may be held directly in 32-bit or 64-bit
registers when being loaded, stored, or converted to other types and sizes.
...
In other words, we may emit instead:
...
.reg.u32 %r22;
ld.u32 %r22, [%frame];
st.u16 [%frame+4], %r22;
...
[Bug debug/96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug debug/96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 Richard Biener changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] Full |[8/9/10 Regression] Full |ABI information missing |ABI information missing |from GCC compiled C |from GCC compiled C Known to fail|11.0|10.2.0 --- Comment #26 from Richard Biener --- For the C familiy this should now be fixed on trunk.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #25 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c6ef9d8d3f11221df1ea6358b8d4e79e42f074fb commit r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb Author: Richard Biener Date: Thu Jul 30 11:46:43 2020 +0200 debug/96383 - emit debug info for used external functions This makes sure to emit full declaration DIEs including formal parameters for used external functions. This helps debugging when debug information of the external entity is not available and also helps external tools cross-checking ABI compatibility which was the bug reporters use case. For cc1 this affects debug information size as follows: VM SIZE FILE SIZE ++ GROWING ++ [ = ] 0 .debug_info +1.63Mi +1.3% [ = ] 0 .debug_str +263Ki +3.4% [ = ] 0 .debug_abbrev +101Ki +4.9% [ = ] 0 .debug_line +5.71Ki +0.0% +44% +16 [Unmapped]+48 +1.2% -- SHRINKING -- [ = ] 0 .debug_loc -213 -0.0% -0.0% -48 .text -48 -0.0% [ = ] 0 .debug_ranges -16 -0.0% -0.0% -32 TOTAL +1.99Mi +0.6% and DWARF compression via DWZ can only shave off minor bits here. Previously we emitted no DIEs for external functions at all unless they were referenced via DW_TAG_GNU_call_site which for some GCC revs caused a regular DIE to appear and since GCC 4.9 only a stub without formal parameters. This means at -O0 we did not emit any DIE for external functions but with optimization we emitted stubs. 2020-07-30 Richard Biener PR debug/96383 * langhooks-def.h (lhd_finalize_early_debug): Declare. (LANG_HOOKS_FINALIZE_EARLY_DEBUG): Define. (LANG_HOOKS_INITIALIZER): Amend. * langhooks.c: Include cgraph.h and debug.h. (lhd_finalize_early_debug): Default implementation from former code in finalize_compilation_unit. * langhooks.h (lang_hooks::finalize_early_debug): Add. * cgraphunit.c (symbol_table::finalize_compilation_unit): Call the finalize_early_debug langhook. gcc/c-family/ * c-common.h (c_common_finalize_early_debug): Declare. * c-common.c: Include debug.h. (c_common_finalize_early_debug): finalize_early_debug langhook implementation generating debug for extern declarations. gcc/c/ * c-objc-common.h (LANG_HOOKS_FINALIZE_EARLY_DEBUG): Define to c_common_finalize_early_debug. gcc/cp/ * cp-objcp-common.h (LANG_HOOKS_FINALIZE_EARLY_DEBUG): Define to c_common_finalize_early_debug. gcc/testsuite/ * gcc.dg/debug/dwarf2/pr96383-1.c: New testcase. * gcc.dg/debug/dwarf2/pr96383-2.c: Likewise. libstdc++-v3/ * testsuite/20_util/assume_aligned/3.cc: Use -g0.
[Bug libstdc++/96279] build failure: floating_from_chars.cc:310:22: error: '__builtin_isinf_sign' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96279 --- Comment #5 from Jonathan Wakely --- Fixed by r11-2439 but I want to keep this open because the cross-config is still wrong.
[Bug c++/96360] ICE in tree check: expected integer_cst, have truth_orif_expr in get_len, at tree.h:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96360 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-07-31 --- Comment #1 from rsandifo at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/96279] build failure: floating_from_chars.cc:310:22: error: '__builtin_isinf_sign' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96279 --- Comment #4 from Zdenek Sojka --- I can no longer reproduce this: r11-2420 (BAD), r11-2449 (OK)
[Bug target/96366] [AArch64] ICE due to lack of support for VNx2SI sub instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96366
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-07-31
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Bu Le from comment #2)
> (In reply to rsand...@gcc.gnu.org from comment #1)
> > (In reply to Bu Le from comment #0)
> > Hmm. In general, the lack of a vector pattern shouldn't case ICEs,
> > but I suppose the add/sub pairing is somewhat special because of
> > the canonicalisation rules. It would be worth looking at exactly
> > why we generate the subtract though, just to confirm that this is
> > an “expected” ICE rather than a symptom of a deeper problem.
>
> Sure. The logic is that the subtraction will be expanded in expr.c:8989,
> before which I believe it still works fine. The gimple to be expand is
>
> vect__5.16_77 = { 4294967273, 4294967154, 4294967294, 4294967265 } -
> vect__1.14_73
Yeah. What I was worried about was: why did we generate this
in the first place if the target doesn't support it?
But it looks like the answer is that, after
g:bb3ab62a8b4a108f01ea2eddfe31e9f733bd9cb6, SVE now advertises
support for both unpacked addition *and* unpacked negation.
Initially we generate a supported vector negation:
vect_a0_52.15_78 = vect__1.14_73 + { 23, 142, 2, 31 };
vect__5.16_77 = -vect_a0_52.15_78;
and this later gets folded into the subtraction above.
Before the patch there was no ICE.
Generating a subtraction out of an addition seemed odd since
canonicalisations usually go the other way. But if the target
says it supports negation too then that changes things. It doesn't
make much sense to support addition and negation but not subtraction.
I think that's enough to show that the patch to the .md file
is the right fix and isn't papering over a problem elsewhere.
Could you post it to gcc-patches?
[Bug middle-end/96390] [OpenMP] Link errors on the offload side for C++ code with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390 --- Comment #2 from Tobias Burnus --- omp-offload.c's omp_discover_declare_target_tgt_fn_r sees the ::S()" It does not call ((vec *) data)->safe_push (*tp); to add it to the work list. (→ follow up issue for "V"?) However, it sets the attribute (+ updates the node); in omp_discover_declare_target_tgt_fn_r: (gdb) p *tp $27 = (tree) 0x77648e00 (gdb) p debug_tree((*tp)->decl_common.attributes) >> But later in dump_function_to_file: (gdb) p fndecl $30 = (tree) 0x77648f00 (gdb) p debug_tree(fndecl->decl_common.attributes) $31 = void Thus, there is now a different tree – with DECL_ATTRIBUTES stripped.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #24 from rguenther at suse dot de --- On Fri, 31 Jul 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 > > --- Comment #23 from Jakub Jelinek --- > I guess one question is what will e.g. LTO do when merging a DECL_IGNORED > DECL_EXTERNAL FUNCTION_DECL with !DECL_IGNORED definition. And also what other side effects the flag has, like no GNU_call_site tags for a call to such function maybe? Who knows. I'm posting the langhook variant now
[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #7 from Martin Liška --- Started with r10-6299-g845bb366adcf702331de3d8022fd0e1c1c918607. Honza can you please take a look?
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #23 from Jakub Jelinek --- I guess one question is what will e.g. LTO do when merging a DECL_IGNORED DECL_EXTERNAL FUNCTION_DECL with !DECL_IGNORED definition.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #22 from Eric Botcazou --- On the other hand, if all it takes to avoid the new DIEs is to set the DECL_IGNORED_P flag, then it might be simpler to go ahead with the change and set the flag in Ada more often.
[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 --- Comment #10 from Jonathan Wakely --- (In reply to S. Davis Herring from comment #9) > > But it's not a DR, so it only applies to C++17 and not C++14 or older > > standards. > > Isn't it? Its motion does say "accept as Defect Reports". I'm only going by what the issues list says. If that's wrong we should ask Mike to update it.
[Bug middle-end/96334] [og10] ICEs with commit 0122024b1908497bfe520361798579895bd75588 "openacc: Shared memory layout optimisation"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96334 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Thomas Schwinge --- Julian, thanks for fixing this in og10 commit g:f5de50b186d6aee39299d01ee98e9a3bcfd80d1a "openacc: Unshare reduction temporaries for GCN". Please remember to put PR markers into the commit log/ChangeLog snippets, so that PRs get updated automatically.
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 Martin Liška changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #13 from Martin Liška --- (In reply to Richard Biener from comment #10) > The partially reduced (In reply to Martin Liška from comment #9) > > Created attachment 48962 [details] > > Partially reduced test-case > > > > The reduction is quite stuck at this point. > > No longer keys on -fPIC though, so the bisection for this is likely wrong. You are right, without the -fPIC argument, for 1GB memory limit, first bad is: r5-4790-g43722f9fa69d4cc9 where the previous revision only needs ~190MB. > -fno-schedule-insns2 improves it from 18s to 5s compile time and from > 1.1GB of peak RSS to 320MB. > > scheduling 2 : 12.69 ( 71%) 0.10 ( 67%) 12.79 ( > 70%) 11128 kB ( 16%) > > -fmem-report doesn't show anything interesting, looking for heap allocations > now to find the offender. > > Can you bisect your reduced testcase again? GCC 8.4 behaves the same for it > rather than being good but GCC 4.8.5 is fine.
[Bug fortran/96398] ASSOCIATE with pointer fails in older GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96398 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Fixed with r8-3248-g62d3c075d52f1b92.
[Bug fortran/96398] ASSOCIATE with pointer fails in older GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96398 --- Comment #2 from Menno Deij - van Rijswijk --- Ok, thanks for clearing that up. We'll stick to newer versions of the compiler :)
[Bug fortran/96398] ASSOCIATE with pointer fails in older GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96398 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Versions older than GCC 8 are no longer maintained. Thus fixed - as you noticed youself.
[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288 --- Comment #11 from Richard Biener --- So var-tracking should be down (still slow) on this testcase now.
[Bug tree-optimization/96369] [8/9/10 Regression] Wrong evaluation order of || operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369 Richard Biener changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] Wrong |Wrong evaluation order of |evaluation order of || ||| operator |operator Known to fail|11.0|10.2.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/96369] [8/9/10 Regression] Wrong evaluation order of || operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.5
[Bug tree-optimization/96369] [8/9/10/11 Regression] Wrong evaluation order of || operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:10231958fcfb13bc4847729eba21470c101b4a88 commit r11-2450-g10231958fcfb13bc4847729eba21470c101b4a88 Author: Richard Biener Date: Fri Jul 31 08:41:56 2020 +0200 middle-end/96369 - fix missed short-circuiting during range folding This makes the special case of constant evaluated LHS for a short-circuiting or/and explicit rather than doing range merging and eventually exposing a side-effect that shouldn't be evaluated. 2020-07-31 Richard Biener PR middle-end/96369 * fold-const.c (fold_range_test): Special-case constant LHS for short-circuiting operations. * c-c++-common/pr96369.c: New testcase.
[Bug d/96393] [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393 --- Comment #3 from Iain Buclaw --- If its one of the two 6ee874f1353933b1427b5e2953358eb3424090d5 or 7d4ee8bc5843997cdc4408848ab2d9ec82f085b2, then it'll be the former. But doing a bisect nonetheless.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #21 from rguenther at suse dot de --- On Fri, 31 Jul 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 > > --- Comment #20 from Jakub Jelinek --- > lang_hooks.finalize_early_debug_info ? > In the default definition move there just the > /* Emit early debug for reachable functions, and by consequence, > locally scoped symbols. */ > struct cgraph_node *cnode; > FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (cnode) > (*debug_hooks->early_global_decl) (cnode->decl); > and for c-family do what you were testing? Hmm, works for me I guess.
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 Richard Biener changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #12 from Richard Biener --- None of the various scheduler --params has any effect. selective scheduling is also affected.
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 Richard Biener changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #11 from Richard Biener --- (In reply to Richard Biener from comment #10) > The partially reduced (In reply to Martin Liška from comment #9) > > Created attachment 48962 [details] > > Partially reduced test-case > > > > The reduction is quite stuck at this point. > > No longer keys on -fPIC though, so the bisection for this is likely wrong. > -fno-schedule-insns2 improves it from 18s to 5s compile time and from > 1.1GB of peak RSS to 320MB. > > scheduling 2 : 12.69 ( 71%) 0.10 ( 67%) 12.79 ( > 70%) 11128 kB ( 16%) > > -fmem-report doesn't show anything interesting, looking for heap allocations > now to find the offender. > > Can you bisect your reduced testcase again? GCC 8.4 behaves the same for it > rather than being good but GCC 4.8.5 is fine. For the testcase most time is spent in constrain_operands and update_conflict_hard_regno_costs. It looks like the main issue is a very large chain of dependences and thus going from 27000 schedule_insn calls to 10 000 000 calls to try_ready which means the sd_iterator iterates over many dependent instructions, not stopping at "common dependences". That's likely also the source of the memory use (the dn_pool), though memory reporting with --enable-gather-detailed-mem-stats doesn't seem to work for this pool? dep_nodesched-deps.c:4107 (sched_deps_init) 1 0 : 0.0%0 0 : 0.0% 80 deps_list sched-deps.c:4105 (sched_deps_init) 1 0 : 0.0% 2179k 136k: 0.9% 16 There's also 10 million dep_replacement nodes which are all allocated via XCNEW ... another object_allocator would be more efficient here I guess. Could it be that sched-deps makes a tree out of a dependence graph? CCing the only active haifa scheduler maintainer...
[Bug c++/96400] New: False positive on Wunused-but-set-variable for static constexpr var used in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96400
Bug ID: 96400
Summary: False positive on Wunused-but-set-variable for static
constexpr var used in lambda
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugbjorn at fahller dot se
Target Milestone: ---
Similar to Bug 96311, but not quite the same.
This code is flags "is_zero" as being unused but set:
template
bool test(Pred p, Val v)
{
return p(v);
}
bool func(int* p)
{
static constexpr auto is_zero = [](auto v) { return v == 0;};
return test([](auto v){return is_zero(*v);}, p);
}
Output:
: In function 'bool func(int*)':
:9:27: warning: variable 'is_zero' set but not used
[-Wunused-but-set-variable]
9 | static constexpr auto is_zero = [](auto v) { return v == 0;};
| ^~~
"is_zero" can correctly be used in the lambda without being captured, since
it's static. The warning only appears when using the extra indirection
"test()". Calling the anonymous lambda directly, without the indirection
"test()", does not display the warning.
Possibly "constexpr" is a red herring above.
Godbolt link:
https://godbolt.org/z/x4zb3s
[Bug c/96399] Arithmetic shift with vector extension becomes logical right shift on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96399 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- s390x defaults to -funsigned-char, while x86_64 defaults to -fsigned-char, so what you get is exactly what should happen. If you want portable code, you should use signed char or unsigned char and use char only if you don't care if it is signed or unsigned.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #20 from Jakub Jelinek --- lang_hooks.finalize_early_debug_info ? In the default definition move there just the /* Emit early debug for reachable functions, and by consequence, locally scoped symbols. */ struct cgraph_node *cnode; FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (cnode) (*debug_hooks->early_global_decl) (cnode->decl); and for c-family do what you were testing?
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #19 from rguenther at suse dot de --- On Fri, 31 Jul 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 > > --- Comment #18 from Jakub Jelinek --- > (In reply to rguent...@suse.de from comment #17) > > Well, not sure - FEs do quite a good job with unused warnings by > > simply tracking things with TREE_USED so I guess global extern decls > > can be tracked as used/unused as well by FEs and what is a use > > (and worth emitting debug for) may be better decided by the FE, > > say for offsetof (X, m) we maybe want debug info for X even if it > > is not otherwise used? > > Perhaps for C, but for C++ with thousands of inline functions everywhere > pretty > much everything is TREE_USED. True... So we could add lang_hooks.finalize_fndecl_referenced_from_final_symboltable () with the default implementation registering debug for nodes with bodies and for C/C++ override this to also register debug for externals? Not sure if we should hand it the cgraph node or whether FEs should figure out whether it is an alias or thunk in their own representation. Ada could leave it as default or do nothing in it. We need a better name though. Not sure if we need to ever do sth else from that hook and thus make it sepecific for debug emission...
[Bug c/96399] Arithmetic shift with vector extension becomes logical right shift on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96399 --- Comment #1 from Yohei Ueda --- Output of gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/s390x-linux-gnu/10.2.0/lto-wrapper Target: s390x-linux-gnu Configured with: /usr/src/gcc/configure --build=s390x-linux-gnu --disable-multilib --enable-languages=c,c++,fortran,go Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC)
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 --- Comment #10 from Richard Biener --- The partially reduced (In reply to Martin Liška from comment #9) > Created attachment 48962 [details] > Partially reduced test-case > > The reduction is quite stuck at this point. No longer keys on -fPIC though, so the bisection for this is likely wrong. -fno-schedule-insns2 improves it from 18s to 5s compile time and from 1.1GB of peak RSS to 320MB. scheduling 2 : 12.69 ( 71%) 0.10 ( 67%) 12.79 ( 70%) 11128 kB ( 16%) -fmem-report doesn't show anything interesting, looking for heap allocations now to find the offender. Can you bisect your reduced testcase again? GCC 8.4 behaves the same for it rather than being good but GCC 4.8.5 is fine.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #18 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #17) > Well, not sure - FEs do quite a good job with unused warnings by > simply tracking things with TREE_USED so I guess global extern decls > can be tracked as used/unused as well by FEs and what is a use > (and worth emitting debug for) may be better decided by the FE, > say for offsetof (X, m) we maybe want debug info for X even if it > is not otherwise used? Perhaps for C, but for C++ with thousands of inline functions everywhere pretty much everything is TREE_USED.
[Bug c/96399] New: Arithmetic shift with vector extension becomes logical right shift on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96399
Bug ID: 96399
Summary: Arithmetic shift with vector extension becomes logical
right shift on s390x
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yohei at jp dot ibm.com
Target Milestone: ---
When I applied arithmetic shift (>>) to a 16-element signed char vector
variable, I observed behavior of logical right shift on s390x.
-
#include
typedef char vec16char __attribute__ ((vector_size (16)));
void test(vec16char *p, vec16char *q)
{
*q = *p >> 7;
}
int main(int argc, char *argv[])
{
vec16char in = {0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80};
vec16char out;
test(&in, &out);
printf("out[0] = %d\n", out[0]);
}
-
I compiled the above code with gcc -Wall -march=z14 -O3 -o vectest vectest.c
Then, I got the following output on s390x:
out[0] = 1
I expected the following output:
out[0] = -1
At least on x86_64, I got the expected output.
On s390x, vesrlb is generated, but I think vesrab is appropriate.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #17 from rguenther at suse dot de --- On Fri, 31 Jul 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 > > --- Comment #15 from Jakub Jelinek --- > Unless we want for C/C++ to emit DW_AT_external DIEs for all function > prototypes that appear in the TU, we need ME help, because only there we > analyze the callgraph and prune cgraph nodes that are unreachable. Well, not sure - FEs do quite a good job with unused warnings by simply tracking things with TREE_USED so I guess global extern decls can be tracked as used/unused as well by FEs and what is a use (and worth emitting debug for) may be better decided by the FE, say for offsetof (X, m) we maybe want debug info for X even if it is not otherwise used?
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #16 from Eric Botcazou --- > So, for Ada, would you like to preserve current behavior rather than what > Richard's patch does? > If so, can't we have a langhook that decides that? > I don't know much about Ada, but would think that having the prototypes even > for functions defined in other shared libraries if they are called or > referenced in the TU is useful even for Ada. This yields useless duplication in 99.99% of the cases though and the debug info is already large enough. Can't you do this from the front-end instead, for the c-family of compilers?
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #15 from Jakub Jelinek --- Unless we want for C/C++ to emit DW_AT_external DIEs for all function prototypes that appear in the TU, we need ME help, because only there we analyze the callgraph and prune cgraph nodes that are unreachable.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #14 from Richard Biener --- (In reply to Jakub Jelinek from comment #13) > (In reply to Eric Botcazou from comment #12) > > > So with the attached 'updated patch' I see > > > > > > === gnat tests === > > > > > > > > > Running target unix/ > > > FAIL: gnat.dg/debug11_pkg.adb scan-assembler-not foreign_imported_func > > > FAIL: gnat.dg/debug9.adb scan-assembler-times (DIE > > > (0x[a-f0-9]*) > > > DW_ > > > TAG_type_unit) 0 > > > > > > where the first FAIL seems obvious from the name of > > > 'foreign_imported_func' > > > and the changed outcome is expected and OK? > > > > The annoying thing is the discrepancy with the variable case; in other > > words, the patch is undercutting gnat_write_global_declarations > > (utils.c:5913). Ah, indeed. > So, for Ada, would you like to preserve current behavior rather than what > Richard's patch does? > If so, can't we have a langhook that decides that? > I don't know much about Ada, but would think that having the prototypes even > for functions defined in other shared libraries if they are called or > referenced in the TU is useful even for Ada. I think that we need that loop in cgraphunit.c at all shows that frontends are not enough in control... The middle-end cannot really make the best decision on what declarations are worth emitting debug info for so what Ada does looks best here and maybe other FEs should follow suit... Note that Ada does this even when -fsyntax-only (if it supports that). I don't remember exactly but I think we've chosen to emit function DIEs during unit finalization instead of at rest_of_decl_compilation time because of ordering issues (FEs call rest_of_decl_compilation very much too often...). The most simplistic langhook would be to ask the FE whether a specific decl should get debug info (but we have DECL_IGNORED for this already ...?).
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #13 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #12) > > So with the attached 'updated patch' I see > > > > === gnat tests === > > > > > > Running target unix/ > > FAIL: gnat.dg/debug11_pkg.adb scan-assembler-not foreign_imported_func > > FAIL: gnat.dg/debug9.adb scan-assembler-times (DIE (0x[a-f0-9]*) > > DW_ > > TAG_type_unit) 0 > > > > where the first FAIL seems obvious from the name of 'foreign_imported_func' > > and the changed outcome is expected and OK? > > The annoying thing is the discrepancy with the variable case; in other > words, the patch is undercutting gnat_write_global_declarations > (utils.c:5913). So, for Ada, would you like to preserve current behavior rather than what Richard's patch does? If so, can't we have a langhook that decides that? I don't know much about Ada, but would think that having the prototypes even for functions defined in other shared libraries if they are called or referenced in the TU is useful even for Ada.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #12 from Eric Botcazou --- > So with the attached 'updated patch' I see > > === gnat tests === > > > Running target unix/ > FAIL: gnat.dg/debug11_pkg.adb scan-assembler-not foreign_imported_func > FAIL: gnat.dg/debug9.adb scan-assembler-times (DIE (0x[a-f0-9]*) > DW_ > TAG_type_unit) 0 > > where the first FAIL seems obvious from the name of 'foreign_imported_func' > and the changed outcome is expected and OK? The annoying thing is the discrepancy with the variable case; in other words, the patch is undercutting gnat_write_global_declarations (utils.c:5913). > For the second FAIL I see type units for system__secondary_stack_* types > and the extra subroutines are likely the invoked system__secondary_stack_* > functions like > > <1><77>: Abbrev Number: 38 (DW_TAG_subprogram) > <78> DW_AT_external: 1 > <78> DW_AT_name: (indirect string, offset: 0x47): > system__secondar > y_stack__ss_release > <7c> DW_AT_decl_file : 2 > <7d> DW_AT_decl_line : 95 > <7e> DW_AT_decl_column : 14 > <7f> DW_AT_sibling : <0x8e> > <2><83>: Abbrev Number: 39 (DW_TAG_formal_parameter) > <84> DW_AT_name: m > <86> DW_AT_decl_file : 2 > <87> DW_AT_decl_line : 95 > <88> DW_AT_decl_column : 26 > <89> DW_AT_type: <0x8e> > <2><8d>: Abbrev Number: 0 > > note they are not DECL_ARTIFICIAL and also not DECL_IGNORED. Now the > testcase tries to test sth else than no type units at all as its > comment explains. Yes, I agree that there is probably a missing DECL_IGNORED here.
[Bug fortran/96398] New: ASSOCIATE with pointer fails in older GCC versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96398 Bug ID: 96398 Summary: ASSOCIATE with pointer fails in older GCC versions Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: m.deij at marin dot nl Target Milestone: --- When I compile the code below with 6.3.1, I get the following error. Versions 8.3.1 and 9.2.0 are OK (I have no other versions to test with). = print*, b2Ptr%a 1 Error: Symbol 'b2ptr' at (1) has no IMPLICIT type = MODULE bodies IMPLICIT NONE TYPE BodyClass INTEGER :: a END TYPE TYPE(BodyClass),POINTER :: aBody CONTAINS FUNCTION bodies_getBody() result(body) TYPE(BodyClass),POINTER :: body body = aBody END FUNCTION END MODULE MODULE aModule USE bodies IMPLICIT NONE CONTAINS SUBROUTINE try TYPE(BodyClass), POINTER :: bPtr ! no problem assigning a pointer bPtr => bodies_getBody() print *, bPtr%a ! this is problematic ASSOCIATE(b2Ptr => bodies_getBody()) print*, b2Ptr%a END ASSOCIATE END SUBROUTINE END MODULE
