[Bug c++/79030] Compilation failure due to virtual memory exhaustion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79030 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jason Merrill --- Created attachment 44328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44328=edit -fmem-stats dump
[Bug c++/80290] [6/7/8/9 Regression] g++ uses unreasonable amount of memory compiling nested string maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80290 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|6.5 |7.4 --- Comment #32 from Jason Merrill --- Fixed for 7.4/8.2/9.
[Bug c/86340] New: GCC 8.1 produces broken code for m68k with optimization levels above -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86340 Bug ID: 86340 Summary: GCC 8.1 produces broken code for m68k with optimization levels above -O1 Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kalamatee at gmail dot com Target Milestone: --- Compiling the following file for AROS m68k using gcc 8.1 produces broken code -: https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/rom/graphics/finddisplayinfo.c Default command line used -: m68k-aros-gcc -iquote /mnt/NAS/PC/AROS/branches/ABI_V1-Clean/src/rom/graphics/./ -iquote /mnt/NAS/PC/AROS/branches/ABI_V1-Clean/src/rom/graphics -iquote . -Os -fno-strict-aliasing -ffreestanding -fomit-frame-pointer -fbuiltin -Wall -Werror -Wno-pointer-sign -Wno-parentheses -Wno-volatile-register-var -g -D__UTILITY_RELLIBBASE__ -D__OOP_RELLIBBASE__ -fno-ipa-cp -I/mnt/NAS/PC/AROS/branches/ABI_V1-Clean/src/rom/cgfx -DAROS_BUILD_TYPE=AROS_BUILD_TYPE_PERSONAL -DNOLIBINLINE -DADEBUG=1 -DMDEBUG=1 -D__OOP_NOMETHODBASES__ -I/home/test/amiga-m68k-gcc8/bin/amiga-m68k/gen/rom/graphics/graphics/include -include /home/test/amiga-m68k-gcc8/bin/amiga-m68k/gen/rom/graphics/graphics/include/graphics_deflibdefs.h -D__SRCFILENAME__=\"rom/graphics/finddisplayinfo.c\" -c /mnt/NAS/PC/AROS/branches/ABI_V1-Clean/src/rom/graphics/./finddisplayinfo.c -o /home/test/amiga-m68k-gcc8/bin/amiga-m68k/gen/rom/graphics/graphics/finddisplayinfo.o Only optimization levels of -O0 or -O1 produce valid results. The broken code is as follows -: : 0: 2f0emovel %fp,%sp@- 2: 2f02movel %d2,%sp@- 4: 5280addql #1,%d0 6: 6732beqs 3a 8: 206e 0224 moveal %fp@(548),%a0 c: b0fc cmpaw #0,%a0 10: 6608bnes 1a 12: 2008movel %a0,%d0 14: 241fmovel %sp@+,%d2 16: 2c5fmoveal %sp@+,%fp 18: 4e75rts 1a: 2228 0008 movel %a0@(8),%d1 1e: 2401movel %d1,%d2 20: c480andl %d0,%d2 22: b4a8 0004 cmpl %a0@(4),%d2 26: 6716beqs 3e 28: 2050moveal %a0@,%a0 2a: 60e0bras c 2c: b081cmpl %d1,%d0 2e: 67e2beqs 12 30: 5088addql #8,%a0 32: 2210movel %a0@,%d1 34: 74ffmoveq #-1,%d2 36: b481cmpl %d1,%d2 38: 66f2bnes 2c 3a: 91c8subal %a0,%a0 3c: 60d4bras 12 3e: 4681notl %d1 40: c081andl %d1,%d0 42: 41e8 0036 lea %a0@(54),%a0 46: 60eabras 32 It is broken because 0x0004/0x0006 performs an addql to d0 to determine if ID == INVALID_ID, when ID != INVALID_ID it ends up at 0x001a which performs andl against the modified d0, rather than its original value - resulting in the function never finding the correct entry. GCC 6.x produces correct code, however I am unable to test if this regression was introduced with GCC 7 or GCC 8.
[Bug tree-optimization/86339] New: DOM does not handle RHS COND_EXPRs well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86339 Bug ID: 86339 Summary: DOM does not handle RHS COND_EXPRs well Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at redhat dot com Target Milestone: --- As outlined in this discussion of one of Kugan's patches, DOM does not handle statements like x = COND ? val1 : val2; When COND has a known result. The discussion is part of this thread: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01383.html
[Bug target/54640] arm_adjust_block_mem: signed/unsigned comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54640 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Jorn Wolfgang Rennecke from comment #2) > I have reverted my patch because of an objection by Richard Earnshaw Is he still working on this?
[Bug middle-end/56281] missed VRP optimization from undefined left shift in ISO C99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56281 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=31178 --- Comment #4 from Eric Gallager --- (In reply to Vincent Lefèvre from comment #3) > Not the same request. Bug 31178 (VRP can infer a range for b in a >> b and a > << b) is about a range for the second operand b (independent from the value > of the first operand, BTW). Here it is a range for the first operand and the > result. This is quite different due to the asymmetry of shift operators. > > Concerning existing code, there was also much code assuming wrapping in case > of integer overflow for +. Code needs to be fixed or should not be compiled > with options like -std=c99. well even if it isn't a duplicate I'd say it's still at least related enough to go under "See Also"
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 Eric Gallager changed: What|Removed |Added Keywords||easyhack CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Richard Biener from comment #3) > No, it's now possible to implement this optimization (but yes, nobody has > done so sofar). It's on my TODO (with tons of other stuff, of course). > Is that still the case? > As this is an easy task for beginners ... whoever feels like doing it, I'll > review the result. Adding "easyhack" keyword then
[Bug rtl-optimization/11261] Weak code generated for JPEG compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=22258 --- Comment #7 from Eric Gallager --- (In reply to Jorn Wolfgang Rennecke from comment #5) > (In reply to comment #4) > > This bug hasn't been modified in more than 18 months. What is the > > current status of this bug? And is this not really a target specific > > issue for SH with its silly r0, or can other targets also have this > > problem?? > > The sh-elf libraries won't build because of PR 22258. > Because we have sched1 enabled, the scheduling problem is currently > non-existant; the values that are needed in r0 can be calculated > in a different general purpose register, and moved into r0 in time for the > indexed addressing. > However, because of sched1 we now have too high register pressure for other > benchmarks. Vlad proposed at the summit to postpone scheduling after reload > to fix the register pressure issue. Unless his porposed register renaming > schedme can handle this case and snarf the required registers too, we'll > go back to square one. Are you still working on this?
[Bug c/70924] Wrong position for "warning: missing braces around initializer [-Wmissing-braces]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70924 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Eric Gallager --- ASSIGNED because of assignee
[Bug c/70618] better error messages for missing/too many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70618 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Eric Gallager --- ASSIGNED due to assignee
[Bug c++/63392] poor error recovery with missing typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63392 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Eric Gallager --- ASSIGNED since there's an assignee
[Bug c/64743] minor issue with the location of -Wlong-long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64743 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-06-28 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > Eh, I think gcc's current behavior makes sense, the 2nd long is the one that > makes it a long long rather than just a long, since people type left to > right. When typing in order, when you've typed just the 1st long, it won't > have triggered -Wlong-long yet. If anyone still wants to change this, I'm putting this bug in WAITING for 3 months; if there's no reply after that I'll close it as WONTFIX.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #4 from Stephen Kim --- Just in case, this system also includes Google's gc. With the gc, everything that fails with gccgo like this seems all fine. Thus, I think this problem might be in the top-level "go tool," which parses the command line and invokes the sub tools.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 --- Comment #3 from Stephen Kim --- Created attachment 44327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44327=edit strace -f go run hello.go strace -f go run hello.go
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331
Stephen Kim changed:
What|Removed |Added
CC||stephen.kim at oracle dot com
--- Comment #2 from Stephen Kim ---
First of all, the error occurs sometimes but not always.
What is being called "the error" is as follows. Go run hello.go (just say
"hello!" with fmt.Println) sometimes fails to find gccgo itself. However, go
build with a cgo invokation sometimes fails to find cgo and sometimes succeed
with cgo but failed to locate gccgo. I assume that other go commands that
invoke any other subtool would have similar issues but with different error
messages.
Here is the example of failure with go run hello.go:
[aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go
/home/aion1223/install/bin/gccgo: waitid: no such file or directory; output:
"Using built-in specs.\nCOLLECT_GCC=/home/aion1223/install/bin/gccgo\nTarget:
aarch64-unknown-linux-gnu\nConfigured with: ../configure
--enable-languages=c,c++,go --prefix=/home/aion1223/install\nThread model:
posix\ngcc version 9.0.0 20180627 (experimental) (GCC)
\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n
/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/go1 - -quiet
-dumpbase - -mlittle-endian \"-mabi=lp64\" -auxbase -
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../.. -o
/tmp/ccr66E5t.s\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian'
'-mabi=lp64'\n as -EL \"-mabi=lp64\" -o -.o
/tmp/ccr66E5t.s\nCOMPILER_PATH=/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/\nLIBRARY_PATH=/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../:/lib/:/usr/lib/\nCOLLECT_GCC_OPTIONS='-c'
'-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n"
Here are examples of failure with go build that requires cgo:
$ cat ce.go
package main
import "fmt"
/*
const unsigned long long int neg = (const unsigned long long int) -1;
*/
import "C"
func main() {
var i uint64
i = uint64(C.neg)
fmt.Println(i)
}
[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build421481847
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
# command-line-arguments
waitid: no such file or directory
[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build170944385
go tool cgo: waitid: no such file or directory
cgo version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental)
[aion1223@localhost ~]$ rm -fr ~/.cache/go-build; go build -x ~/ce.go
WORK=/tmp/go-build774257621
mkdir -p $WORK/b001/
cd $WORK
/home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true
cd /home/aion1223
CGO_LDFLAGS='"-g" "-O2"'
./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/
-importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
gcc -I /home/aion1223 -fPIC -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -o ./_x001.o -c _cgo_export.c
gcc -I /home/aion1223 -fPIC -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -o ./_x002.o -c ce.cgo2.c
cd $WORK
gcc -fsplit-stack -c -x c - || true
cd /home/aion1223
gcc -Wall -g -I $WORK/b001/ -I ./install/pkg/include -o $WORK/b001/_cgo_defun.o
-D GOOS_linux -D GOARCH_arm64 -fdebug-prefix-map=$WORK=/tmp/go-build
-gno-record-gcc-switches -c $WORK/b001/_cgo_defun.c
cd $WORK
/home/aion1223/install/bin/gccgo -fgo-importcfg=/dev/null -c -x c - || true
cd /home/aion1223
./install/bin/gccgo -c -g -fdebug-prefix-map=$WORK=/tmp/go-build
-gno-record-gcc-switches -fgo-rela
[Bug c++/80290] [6/7/8/9 Regression] g++ uses unreasonable amount of memory compiling nested string maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80290 --- Comment #31 from Jason Merrill --- Author: jason Date: Thu Jun 28 00:25:21 2018 New Revision: 262204 URL: https://gcc.gnu.org/viewcvs?rev=262204=gcc=rev Log: PR c++/80290 - memory-hog with std::pair. * pt.c (type_unification_real): Skip non-dependent conversion check for a nested list argument. (braced_init_depth): New. Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/pt.c
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329 --- Comment #4 from David Malcolm --- Fixed on trunk by r262199; still affects gcc-8 and gcc-7 branches.
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329
--- Comment #3 from David Malcolm ---
Author: dmalcolm
Date: Wed Jun 27 23:21:46 2018
New Revision: 262199
URL: https://gcc.gnu.org/viewcvs?rev=262199=gcc=rev
Log:
C++: don't offer bogus "._0" suggestions (PR c++/86329)
PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
#include
int compare()
{
return __n1 - __n2;
}
suggested.cc: In function 'int compare()':
suggested.cc:5:10: error: '__n1' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:10: note: suggested alternative: '._61'
return __n1 - __n2;
^~~~
._61
suggested.cc:5:17: error: '__n2' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:17: note: suggested alternative: '._72'
return __n1 - __n2;
^~~~
._72
The dot-prefixed names are an implementation detail of how we implement
anonymous enums found in the header files, generated via
anon_aggrname_format in make_anon_name.
This patch uses anon_aggrname_p to filter them out when considering
which names to suggest.
gcc/cp/ChangeLog:
PR c++/86329
* name-lookup.c (consider_binding_level): Filter out names that
match anon_aggrname_p.
gcc/testsuite/ChangeLog:
PR c++/86329
* g++.dg/lookup/pr86329.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/lookup/pr86329.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
[Bug other/86338] [9 regression] hundreds of new test case failures after r262180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86338 --- Comment #2 from Rasmus Villemoes --- I believe and hope Rainer's fix r262195 also takes care of these.
[Bug other/86338] [9 regression] hundreds of new test case failures after r262180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86338 --- Comment #1 from seurer at gcc dot gnu.org --- From some recent test results emails I see this is happened on other architectures as well (at least x86 and aarch64).
[Bug other/86338] New: [9 regression] hundreds of new test case failures after r262180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86338 Bug ID: 86338 Summary: [9 regression] hundreds of new test case failures after r262180 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- These occur during a bootstrap build/test. --- r262180 | villemoes | 2018-06-27 05:04:25 -0500 (Wed, 27 Jun 2018) | 14 lines add support for --disable-gcov For some targets (in my case VxWorks 5.5), libgcov does not compile due to missing functions and macros such as getpid() and F_OK. Incidentally, gcc/Makefile.in already contains comments such as # Install gcov if it was compiled. but there is no logic in place to actually allow gcov to not be compiled. So add an option for disabling build and install of libgcov and the related host tools. FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -O0 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -O1 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -O2 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -O3 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -O3 -g -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -Os -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -g -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O0 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O1 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O2 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -g -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -Os -fprofile-arcs FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -g -fprofile-arcs FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 gcov: 56 failures in line counts, 24 in branch percentages, 0 in return percentages, 0 in intermediate format FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 100: is #:should be 2 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 102: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 103: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 105: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 113: is #:should be 15 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 115: is #:should be 14 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 116: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 118: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 141: is #:should be 5 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 142: expected branch percentages not found: 40 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 143: is #:should be 3 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 145: is #:should be 3 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 150: is #:should be 2 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 152: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 154: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 156: is #:should be 5 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 158: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 160: is #:should be 5 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 161: expected branch percentages not found: 20 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 162: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 164: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 165: is #:should be 5 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 173: is #:should be 6 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 175: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 177: is #:should be 6 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 181: is #:should be 6 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 183: is #:should be 3 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 185: is #:should be 6 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 187: is #:should be 2 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 189: is #:should be 4 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 192: is #:should be 4 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 200: is #:should be 11 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 202: is #:should be 1 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 204: is #:should be 11 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 205: expected branch percentages not found: 45 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 206: is #:should be 5 FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 line 207: expected branch percentages not found: 40 FAIL: g++.dg/gcov/gcov-1.C
[Bug fortran/82865] Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865 --- Comment #7 from Fritz Reese --- (In reply to Fritz Reese from comment #6) > ... Though I agree -fdec should rarely be mixed with new > Fortran, it is actually simple to patch gfc_match_type() so that it does > match PDTs as a TYPE/PRINT statement. ... s/does/does NOT/
[Bug fortran/82865] Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865 Fritz Reese changed: What|Removed |Added Last reconfirmed|2017-11-06 00:00:00 |2018-6-27 Assignee|pault at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #6 from Fritz Reese --- Actually this is due to gfc_match_type() failing to account for PDT declarations. The function was introduced in r241518 to allow using TYPE as an alias for PRINT with -fdec but was not updated when PDT support was introduced in r251925. Though I agree -fdec should rarely be mixed with new Fortran, it is actually simple to patch gfc_match_type() so that it does match PDTs as a TYPE/PRINT statement. I will submit a patch shortly.
[Bug fortran/69654] ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 Fritz Reese changed: What|Removed |Added Last reconfirmed|2016-02-04 00:00:00 |2018-6-27 --- Comment #5 from Fritz Reese --- Ah, indeed, the original case does still segfault (even since 7.2.1), only the reduced case from Comment #2 was fixed in r254427. My mistake.
[Bug fortran/83184] Out of memory or ICE with option -fdec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184 --- Comment #2 from Fritz Reese --- This is really two separate bugs; the first being that the locus of the variable expression is unset from match_old_style_init(), which can be seen in the simpler test case: $ cat z1.f90 integer n1(..) /1/ end $ gfortran z1.f90 z1.f90:1:13: integer n(..) /1/ 1 Error: Assumed-rank array at (1) must be a dummy argument f951: internal compiler error: Segmentation fault 0xd9b2af crash_signal /data/midas/foreese/src/gcc-trunk/gcc/toplev.c:325 0x8c868c traverse_data_list /data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:15450 0x8c868c traverse_data_var /data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:15530 0x8ba7c3 resolve_data /data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:15587 0x8ba7c3 resolve_types /data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:16405 0x8bf4ac gfc_resolve(gfc_namespace*) /data/midas/foreese/src/gcc-trunk/gcc/fortran/resolve.c:16494 0x8ad424 resolve_all_program_units /data/midas/foreese/src/gcc-trunk/gcc/fortran/parse.c:6042 0x8ad424 gfc_parse_file() /data/midas/foreese/src/gcc-trunk/gcc/fortran/parse.c:6292 0x8f326f gfc_be_parse_file /data/midas/foreese/src/gcc-trunk/gcc/fortran/f95-lang.c:204 The second bug is the out-of-memory issue from within match_clist_expr().
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug fortran/83184] Out of memory or ICE with option -fdec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184 Fritz Reese changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/69654] ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #4 from Dominique d'Humieres --- I still get an ICE when compiling (r261796) the original test in comment 0: pr69654.f90:45:0: end subroutine foo_script1 internal compiler error: Segmentation fault: 11
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329 --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01694.html
[Bug libstdc++/86280] experimental/memory_resource overflows 32 bit type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86280 Jonathan Wakely changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- *** Bug 86335 has been marked as a duplicate of this bug. ***
[Bug libstdc++/86335] [9 regression] libstdc++ memory_resource gives error on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86335 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Already fixed at r261888 *** This bug has been marked as a duplicate of bug 86280 ***
[Bug libstdc++/86333] [9 regression] libstdc++ basic_string fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86333 --- Comment #1 from Jonathan Wakely --- Was this fixed by r261892 ?
[Bug middle-end/86332] Incorrect warning with Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86332 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- Invalid.
[Bug middle-end/86332] Incorrect warning with Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86332 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Oops, looks like I messed up reducing the test-case from the original program which triggered this bug -;( Sorry for the noise.
[Bug fortran/69654] ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 Fritz Reese changed: What|Removed |Added Status|NEW |RESOLVED CC||foreese at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Target Milestone|--- |7.2 --- Comment #3 from Fritz Reese --- This was apparently fixed by Paul in r254427 for 7.2.1 as a side-effect of fixing PR 81447 and PR 82783.
[Bug fortran/86337] New: [9 regression] gfortran segmentation fault in resolve.c:3119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86337 Bug ID: 86337 Summary: [9 regression] gfortran segmentation fault in resolve.c:3119 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- Recently the gfortran.dg/typebound_proc_35.f90 -Os test fails as follows: f951: internal compiler error: Segmentation fault 0xc58e8f crash_signal buildbot/native-glibc-aarch64-none-linux-gnu/build/src/gcc/gcc/toplev.c:324 0x6a97c8 resolve_function buildbot/native-glibc-aarch64-none-linux-gnu/build/src/gcc/gcc/fortran/resolve.c:3119 0x6a7097 gfc_resolve_expr(gfc_expr*) buildbot/native-glibc-aarch64-none-linux-gnu/build/src/gcc/gcc/fortran/resolve.c:6741
[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57891 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #7 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01691.html
[Bug middle-end/86336] New: [9 regression] ICE in omp-low.c:7879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86336 Bug ID: 86336 Summary: [9 regression] ICE in omp-low.c:7879 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- Recently omp-low.c started to show an ICE: UNRESOLVED: libgomp.oacc-c++/non-scalar-data.C -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -O2 compilation failed to produce executable Excess errors: during GIMPLE pass: omplower buildbot/native-glibc-aarch64-none-linux-gnu/build/src/gcc/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C:58:9: internal compiler error: in lower_omp_target, at omp-low.c:7879 0xcf35fb lower_omp_target buildbot/native-glibc-aarch64-none-linux-gnu/build/src/gcc/gcc/omp-low.c:7879 It appears to be due to r261813.
[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-27 Ever confirmed|0 |1 --- Comment #1 from Ian Lance Taylor --- I'm not clear: does the error "waitid: no such file or directory" happen randomly, or does it happen every time? It looks like calling the waitid system call is returning ENOENT. I don't know what that would happen. Can you attach the output of `strace -f` for a failing run? Thanks.
[Bug libstdc++/86335] New: [9 regression] libstdc++ memory_resource gives error on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86335 Bug ID: 86335 Summary: [9 regression] libstdc++ memory_resource gives error on 32-bit targets Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- The following warning happens when you use memory_resource: ...libstdc++-v3/include/experimental/memory_resource:329: warning: left shift count >= width of type [-Wshift-count-overflow] This is due to r261849: if (_M_align <= (1ul << (sizeof(int) * __CHAR_BIT__))) return sizeof(int); These tests fail as a result: FAIL: experimental/memory_resource/1.cc (test for excess errors) FAIL: experimental/memory_resource/70966.cc (test for excess errors) FAIL: experimental/memory_resource/new_delete_resource.cc (test for excess errors) FAIL: experimental/memory_resource/null_memory_resource.cc (test for excess errors) FAIL: experimental/memory_resource/resource_adaptor.cc (test for excess errors) FAIL: experimental/type_erased_allocator/2.cc (test for excess errors)
[Bug target/86334] New: wrong code with -march=athlon -mmemcpy-strategy=libcall:-1:noalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86334
Bug ID: 86334
Summary: wrong code with -march=athlon
-mmemcpy-strategy=libcall:-1:noalign
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu
Created attachment 44326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44326=edit
reduced testcase
Output:
$ i686-pc-linux-gnu-gcc -O -march=athlon -minline-all-stringops
-minline-stringops-dynamically -mmemcpy-strategy=libcall:-1:noalign testcase.c
testcase.c: In function 'foo':
testcase.c:5:1: warning: AVX512F vector return without AVX512F enabled changes
the ABI [-Wpsabi]
{
^
$ ./a.out
Aborted
There is missing any initialization of the data -> it contains any garbage just
present on the stack.
$ i686-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-i686/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-262017-checking-yes-rtl-df-extra-i686/bin/../libexec/gcc/i686-pc-linux-gnu/9.0.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-sysroot=/usr/i686-pc-linux-gnu
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-pc-linux-gnu --with-ld=/usr/bin/i686-pc-linux-gnu-ld
--with-as=/usr/bin/i686-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-262017-checking-yes-rtl-df-extra-i686
Thread model: posix
gcc version 9.0.0 20180625 (experimental) (GCC)
[Bug middle-end/86332] Incorrect warning with Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86332 --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- Created attachment 44325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44325=edit Untested fix
[Bug libstdc++/86333] New: [9 regression] libstdc++ basic_string fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86333 Bug ID: 86333 Summary: [9 regression] libstdc++ basic_string fails to link Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- Recently these tests started to fail on arm-none-linux-gnueabihf: FAIL: 21_strings/basic_string/modifiers/64422.cc (test for excess errors) FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc (test for excess errors) FAIL: 21_strings/basic_string/modifiers/insert/wchar_t/1.cc (test for excess errors) FAIL: ext/pb_ds/regression/tree_map_rand.cc (test for excess errors) FAIL: ext/pb_ds/regression/tree_set_rand.cc (test for excess errors) FAIL: ext/pb_ds/regression/trie_map_rand.cc (test for excess errors) FAIL: ext/pb_ds/regression/trie_set_rand.cc (test for excess errors) FAIL: g++.dg/torture/pr60750.C -O0 (test for excess errors) FAIL: g++.dg/torture/pr60750.C -Os (test for excess errors) UNRESOLVED: 21_strings/basic_string/modifiers/insert/char/1.cc compilation failed to produce executable UNRESOLVED: 21_strings/basic_string/modifiers/insert/wchar_t/1.cc compilation failed to produce executable UNRESOLVED: ext/pb_ds/regression/tree_map_rand.cc compilation failed to produce executable UNRESOLVED: ext/pb_ds/regression/tree_set_rand.cc compilation failed to produce executable UNRESOLVED: ext/pb_ds/regression/trie_map_rand.cc compilation failed to produce executable UNRESOLVED: ext/pb_ds/regression/trie_set_rand.cc compilation failed to produce executable UNRESOLVED: g++.dg/torture/pr60750.C -O0 compilation failed to produce executable UNRESOLVED: g++.dg/torture/pr60750.C -Os compilation failed to produce executable Looking at g++.dg/torture/pr60750.C, the generated code hasn't changed, but the library no longer contains this symbol: pr60750.C:(.text._ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_OS8_[_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_OS8_]+0x12): undefined reference to `std::__cxx11::basic_string, std::allocator >::insert(unsigned int, std::__cxx11::basic_string, std::allocator > const&)' collect2: error: ld returned 1 exit status
[Bug middle-end/86332] New: Incorrect warning with Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86332
Bug ID: 86332
Summary: Incorrect warning with Wstringop-overflow
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
Hi,
For the following test-case:
void foo(void)
{
void escape(unsigned char *);
unsigned char tmp[12];
unsigned char *p = tmp + 7;
__builtin_memset (p, 0, 6);
escape (p);
}
I get warning:
test.c: In function ‘foo’:
test.c:7:3: warning: ‘__builtin_memset’ writing 6 bytes into a region of size 5
overflows the destination [-Wstringop-overflow=]
__builtin_memset (p, 0, 6);
^~
Seems like an "off by one" mistake. Doesn't warn if size of tmp is increased by
1.
[Bug go/86331] New: the gccgo's "go" tool looks like failing to invoke any sub go command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86331 Bug ID: 86331 Summary: the gccgo's "go" tool looks like failing to invoke any sub go command Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: stephen.kim at oracle dot com CC: cmang at google dot com Target Milestone: --- It seems that putting back a new version of go to gcc8 triggers the issue I would describe here. Invoking any go command randomly fails in aarch64: [aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go hello! [aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go hello! [aion1223@localhost gcc_upstream]$ go run /home/aion1223/hello.go /home/aion1223/install/bin/gccgo: waitid: no such file or directory; output: "Using built-in specs.\nCOLLECT_GCC=/home/aion1223/install/bin/gccgo\nTarget: aarch64-unknown-linux-gnu\nConfigured with: ../configure --enable-languages=c,c++,go --prefix=/home/aion1223/install\nThread model: posix\ngcc version 9.0.0 20180627 (experimental) (GCC) \nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n /home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/go1 - -quiet -dumpbase - -mlittle-endian \"-mabi=lp64\" -auxbase - -L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0 -L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../.. -o /tmp/ccr66E5t.s\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n as -EL \"-mabi=lp64\" -o -.o /tmp/ccr66E5t.s\nCOMPILER_PATH=/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/libexec/gcc/aarch64-unknown-linux-gnu/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/\nLIBRARY_PATH=/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/aion1223/install/lib/gcc/aarch64-unknown-linux-gnu/9.0.0/../../../:/lib/:/usr/lib/\nCOLLECT_GCC_OPTIONS='-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64'\n" Please, note that there has been no change in the hello.go. Go run is not the only command to fail. [aion1223@localhost gcc_upstream]$ go build -x ~/ce.go WORK=/tmp/go-build231706713 go tool cgo: waitid: no such file or directory cgo version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental) [aion1223@localhost gcc_upstream]$ go build -x ~/ce.go WORK=/tmp/go-build583342013 mkdir -p $WORK/b001/ cd $WORK /home/aion1223/install/bin/gccgo -fsplit-stack -c -x c - || true cd /home/aion1223 CGO_LDFLAGS='"-g" "-O2"' ./install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cgo -objdir $WORK/b001/ -importpath command-line-arguments -gccgo -- -I $WORK/b001/ -g -O2 ./ce.go # command-line-arguments waitid: no such file or directory Also, please note that the two commands issued were the same although the output is different. Here are some information about my system: [aion1223@localhost gcc_upstream]$ go version go version go1.10.3 gccgo (GCC) 9.0.0 20180627 (experimental) linux/arm64 [aion1223@localhost gcc_upstream]$ gcc --version gcc (GCC) 9.0.0 20180627 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [aion1223@localhost gcc_upstream]$ uname -a Linux localhost 4.13.0-1.0.5.2.el7.aarch64 #1 SMP Wed Nov 1 18:33:55 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux Basically, this is a VM running on an arm64 machine. This problem goes away if the failed command/subtool is invoked with Google's gc's go tool with -compiler=gccgo.
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329
--- Comment #1 from David Malcolm ---
Confirmed on trunk, gcc-8, and gcc-7.
Doesn't affect gcc-6.
The bogus dotted names are coming from anonymous enums in the header; a more
minimal reproducer is:
enum {};
int test()
{
return __0;
}
pr86329.C: In function ‘int test()’:
pr86329.C:5:10: error: ‘__0’ was not declared in this scope
return __0;
^~~
pr86329.C:5:10: note: suggested alternative: ‘._0’
return __0;
^~~
._0
I'm working on a fix.
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-27 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/83184] Out of memory or ICE with option -fdec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184 Fritz Reese changed: What|Removed |Added Last reconfirmed|2017-11-27 00:00:00 |2018-6-27 Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org Target Milestone|--- |8.2
[Bug c++/61183] Large memory usage with smallish C++ templates (> 16GB)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61183 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-27 Ever confirmed|0 |1
[Bug c++/61183] Large memory usage with smallish C++ templates (> 16GB)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61183 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- Created attachment 44324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44324=edit dump_ggc_loc_statistics from xmalloc_failed It's actually dying during early inlining, at least in my GATHER_STATISTICS build. Here's the mem-stats dump and backtrace from the point where allocation fails. The plurality of garbage is coming from inlining: tree-inline.c:5052 (copy_tree_r) 377222112: 45.7% The plurality of memory still held at the crash point is from toplev.c:918 (realloc_for_line_map) 0: 0.0% 1346560: 0.2% 1340850216: 22.7% 268434456: 94.0%22 But the enormous allocation that kills the compiler is for expanding the mem_usage hash table.
[Bug target/69744] OpenBSD does not define max_align_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69744 Jonathan Wakely changed: What|Removed |Added Target||*-*-openbsd* Component|libstdc++ |target --- Comment #5 from Jonathan Wakely --- Changing component from libstdc++ to target, since this should be fixed in the t-openbsd configure fragment, not in libstdc++.
[Bug demangler/85453] OOM-Bug in cxxfilt / C++ name demangler (binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85453 Simon Wörner changed: What|Removed |Added CC||gcc.gnu.org at brn dot li --- Comment #1 from Simon Wörner --- $ valgrind binutils/cxxfilt -t < ./oom ==11187== Memcheck, a memory error detector ==11187== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==11187== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==11187== Command: binutils/cxxfilt -t ==11187== ==11187== ==11187== Process terminating with default action of signal 2 (SIGINT) ==11187==at 0x4C367E0: memmove (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11187==by 0x1DA254: memcpy (string_fortified.h:34) ==11187==by 0x1DA254: remember_Ktype (cplus-dem.c:4430) ==11187==by 0x1DE5F4: demangle_qualified (cplus-dem.c:3495) ==11187==by 0x1DF736: demangle_signature (cplus-dem.c:1495) ==11187==by 0x1E0A62: internal_cplus_demangle (cplus-dem.c:1257) ==11187==by 0x1DB53B: cplus_demangle (cplus-dem.c:918) ==11187==by 0x13A2B3: demangle_it (cxxfilt.c:62) ==11187==by 0x139F61: main (cxxfilt.c:276) ==11187== ==11187== HEAP SUMMARY: ==11187== in use at exit: 2,506,806,484 bytes in 50,064 blocks ==11187== total heap usage: 50,092 allocs, 28 frees, 2,507,614,296 bytes allocated ==11187== ==11187== LEAK SUMMARY: ==11187==definitely lost: 100,119 bytes in 1 blocks ==11187==indirectly lost: 0 bytes in 0 blocks ==11187== possibly lost: 0 bytes in 0 blocks ==11187==still reachable: 2,506,706,365 bytes in 50,063 blocks ==11187== suppressed: 0 bytes in 0 blocks ==11187== Rerun with --leak-check=full to see details of leaked memory ==11187== ==11187== For counts of detected and suppressed errors, rerun with: -v ==11187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug target/85907] AIX: static libstdc++ and exceptions causes abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85907 David Edelsohn changed: What|Removed |Added Target|*-aix* |powerpc-ibm-aix* Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-27 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug c++/82507] [concepts] premature substitution into constraint of non-template member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82507 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-27 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- We get: g.cc: In instantiation of ‘struct S’: g.cc:13:8: required from here g.cc:10:8: error: ‘int’ is not a class, struct, or union type void foo() requires HasType && True; ^~~
[Bug fortran/86328] [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328 --- Comment #3 from janus at gcc dot gnu.org --- The code in comment 0 seems to have a small error: a%ll is allocated with only one element (1:1), which should probably be ten (1:10). So I wonder why it runs with gfortran-7 at all?!? In any case, here is a corrected and slightly reduced version: program ptr_alloc type :: t class(*), allocatable :: val end type type :: list type(t), dimension(:), pointer :: ll end type integer :: i type(list) :: a allocate(a%ll(1:2)) do i = 1,2 print *,i allocate(a%ll(i)%val, source=i) end do call rrr(a) contains subroutine rrr(a) type(list), intent(in) :: a integer :: s, j type(t), dimension(:), allocatable :: mm s = ubound(a%ll,1) allocate(mm(1:s)) do j = 1, s print *," ",j if (allocated(a%ll(j)%val)) then allocate(mm(j)%val, source=a%ll(j)%val) end if end do end subroutine end This shows basically the same behavior: It runs with gfortran-7 and earlier (and also with ifort, pgi, flang), but segfaults with gfortran-8, where valgrind shows: ==24028== Memcheck, a memory error detector ==24028== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==24028== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==24028== Command: ./a.out ==24028== 1 2 1 ==24028== Use of uninitialised value of size 8 ==24028==at 0x40170A: rrr.3800 (c3.f90:36) ==24028==by 0x4010CF: MAIN__ (c3.f90:20) ==24028==by 0x401EF2: main (c3.f90:20) ==24028== ==24028== Use of uninitialised value of size 8 ==24028==at 0x4017E9: rrr.3800 (c3.f90:36) ==24028==by 0x4010CF: MAIN__ (c3.f90:20) ==24028==by 0x401EF2: main (c3.f90:20) ==24028== ==24028== Use of uninitialised value of size 8 ==24028==at 0x4018BD: rrr.3800 (c3.f90:36) ==24028==by 0x4010CF: MAIN__ (c3.f90:20) ==24028==by 0x401EF2: main (c3.f90:20) ==24028== 2 ==24028== Invalid read of size 8 ==24028==at 0x4017E9: rrr.3800 (c3.f90:36) ==24028==by 0x4010CF: MAIN__ (c3.f90:20) ==24028==by 0x401EF2: main (c3.f90:20) ==24028== Address 0xb285ac0 is not stack'd, malloc'd or (recently) free'd ==24028== Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
[Bug fortran/86330] False positive warnings about uninitialized offset/lbound/ubound when allocating on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86330 --- Comment #1 from Tomáš Trnka --- Looks like a duplicate of bug 85855.
[Bug fortran/86330] New: False positive warnings about uninitialized offset/lbound/ubound when allocating on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86330 Bug ID: 86330 Summary: False positive warnings about uninitialized offset/lbound/ubound when allocating on assignment Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tomastrnka at gmx dot com Target Milestone: --- The following testcase generates false positive warnings because "x" is unallocated before assignment: program realloc_uninitialized implicit none integer, allocatable :: x(:) !allocate(x(0)) !deallocate(x) x = foo() write(*,*) x contains function foo() result(a) integer, allocatable :: a(:) allocate(a(5)) a = 0 end function end program $ gfortran -fdump-tree-original -Wall -O3 -fno-inline -o realloc_uninitialized realloc_uninitialized.f90 realloc_uninitialized.f90:8:0: x = foo() Warning: ‘x.offset’ is used uninitialized in this function [-Wuninitialized] realloc_uninitialized.f90:8:0: Warning: ‘x.dim[0].lbound’ is used uninitialized in this function [-Wuninitialized] realloc_uninitialized.f90:8:0: Warning: ‘x.dim[0].ubound’ is used uninitialized in this function [-Wuninitialized] Uncommenting the allocate/deallocate makes the warning go away. I'm using gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC) (stock Fedora 28 compiler), but I have also seen this previously on GCC 7. My self-compiled gcc version 6.4.1 20180314 (GCC) doesn't trigger the warning. I guess this is because of the following references to "x" at the very start of "realloc_uninitialized ()" in "realloc_uninitialized.f90.003t.original": D.3797 = (integer(kind=4)[0:] * restrict) x.data; D.3798 = x.offset; D.3799 = x.dim[0].lbound; D.3800 = x.dim[0].ubound; None of these D.*s is subsequently used.
[Bug fortran/86328] [8/9 Regression] Runtime segfault reading an allocatable class(*) object in allocate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-27 CC||janus at gcc dot gnu.org Summary|Runtime segfault reading an |[8/9 Regression] Runtime |allocatable class(*) object |segfault reading an |in allocate statements |allocatable class(*) object ||in allocate statements Ever confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org --- I see it fail with 8.1.0 and trunk, while it seems to work with 4.8.5 up to 7.3.0.
[Bug c++/86327] Spurious error on non-constant expression in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86327 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-27 Ever confirmed|0 |1
[Bug c++/86329] New: Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329
Bug ID: 86329
Summary: Bogus fix-it hint: note: suggested alternative: '._72'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
#include
int compare()
{
return __n1 - __n2;
}
suggested.cc: In function 'int compare()':
suggested.cc:5:10: error: '__n1' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:10: note: suggested alternative: '._61'
return __n1 - __n2;
^~~~
._61
suggested.cc:5:17: error: '__n2' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:17: note: suggested alternative: '._72'
return __n1 - __n2;
^~~~
._72
We shouldn't be suggesting ._61 and ._72 since they don't exist in the source
code.
[Bug fortran/86328] Runtime segfault reading an allocatable class(*) object in allocate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328 martin changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86117 --- Comment #1 from martin --- Related bug: PR86117
[Bug fortran/86328] New: Runtime segfault reading an allocatable class(*) object in allocate statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328 Bug ID: 86328 Summary: Runtime segfault reading an allocatable class(*) object in allocate statements Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The following code leads to a runtime segfault: program ptr_alloc type :: t class(*), allocatable :: val end type t type :: list type(t), dimension(:), pointer :: ll integer :: cnt end type list integer :: i type(list) :: a allocate(a%ll(1:1)) do i = 1,10 print *,i a%cnt = i allocate(a%ll(i)%val, source=i) call rrr(a) end do contains subroutine rrr(a) type(list) :: a integer :: s, i type(t), dimension(:), pointer :: mm s = ubound(a%ll,1) + 1 allocate(mm(1:s)) do i = 1, s-1 if (allocated(a%ll(i)%val)) then allocate(mm(i)%val, source=a%ll(i)%val) !allocate(mm(i)%val, mold=a%ll(i)%val) !mm(i)%val = a%ll(i)%val deallocate(a%ll(i)%val) end if end do deallocate(a%ll) a%ll => mm end subroutine rrr end program ptr_alloc Using the commented mold and assignment version also leads to a segfault. Using allocation on assignment (just the commented assignment) works, but then the deallocation statement fails with a segfault. valgrind reports an "Invalid read of size 8".
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #11 from Richard Earnshaw --- (In reply to sameerad from comment #10) > > subus: > >ldr w0, [w0] > >add w0, w0, w0, lsr #16 > >uxth w0, w0 > >ret > > This is interesting way in which load store combining can be enhanced > further. I will try to figure out if this can be integrated in my current > implementation. > > Thanks Richard. In a way, this is just a form of SLP.
[Bug fortran/86117] bogus warning maybe-uninitialized with class(*) and source argument in allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117 janus at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86100 --- Comment #4 from janus at gcc dot gnu.org --- Very likely related to PR 86100.
[Bug fortran/86117] bogus warning maybe-uninitialized with class(*) and source argument in allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117 --- Comment #3 from janus at gcc dot gnu.org --- Here is a variation of the original example that actually runs the routine: module m type :: generic class(*), allocatable :: item end type contains subroutine sub(a, b) type(generic), dimension(:), intent(in) :: a type(generic), dimension(:), intent(out) :: b integer :: i do i = 1, 10 allocate(b(i)%item, source=a(i)%item) end do end end program p use m type(generic) :: x(10), y(10) integer ::i do i=1,10 allocate(x(i)%item, source=i) end do call sub(x,y) end This runs ok without -fcheck=bounds, but segfaults at runtime with this flag (in the allocate line in sub). So I think the warning is probably not bogus, but instead -fcheck=bounds generates wrong code for this case?
[Bug fortran/86117] bogus warning maybe-uninitialized with class(*) and source argument in allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to martin from comment #0) > Compiling the following module with > > gfortran -Og -Wall -fcheck=all -c mod.f90 Out of all the -fcheck options, -fcheck=bounds seems to be the relevant one.
[Bug tree-optimization/86263] [9 Regression] [nvptx] casesi, tablejump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86263
--- Comment #7 from Tom de Vries ---
The pass_lower_switch has no effect. It generates a switch expansion at
bb12, but the function still uses the switch at bb10:
...
(gdb) call debug_function (cfun.decl, 0)
_dcvt (void * ptr, char type, int opt, int val)
{
char D.1454;
int _1;
char _12;
unsigned int _13;
unsigned int _14;
_Bool _15;
long unsigned int _16;
long unsigned int _17;
_Bool _18;
long unsigned int _19;
_Bool _20;
long unsigned int _21;
_Bool _22;
:
_1 = (int) type_3(D);
:
goto ; [100.00%]
:
_13 = (unsigned int) _1;
_14 = _13 + 4294967227;
_15 = _14 > 34;
if (_15 != 0)
goto ; [INV]
else
goto ; [INV]
:
_16 = 1 << _14;
_17 = _16 & 4294967297;
_18 = _17 != 0;
if (_18 != 0)
goto ; [INV]
else
goto ; [INV]
:
_19 = _16 & 17179869188;
_20 = _19 != 0;
if (_20 != 0)
goto ; [INV]
else
goto ; [INV]
:
_21 = _16 & 8589934594;
_22 = _21 != 0;
if (_22 != 0)
goto ; [INV]
else
goto ; [INV]
:
goto ; [INV]
:
switch (_1) [INV], case 69: [INV], case 70: [INV],
case 71: [INV], case 101: [INV], case 102: [INV], case 103:
[INV]>
:
:
f1 (ptr_5(D));
goto ; [INV]
:
:
if (opt_7(D) == 0)
goto ; [INV]
else
goto ; [INV]
:
opt_8 = 1;
:
f2 (ptr_5(D));
goto ; [INV]
:
:
f3 (ptr_5(D));
:
:
_12 = (char) val_11(D);
:
:
return _12;
}
...
[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85769 --- Comment #5 from Tamar Christina --- Author: tnfchris Date: Wed Jun 27 08:08:48 2018 New Revision: 262178 URL: https://gcc.gnu.org/viewcvs?rev=262178=gcc=rev Log: Add SIMD to REG pattern for movhf without armv8.2-a support for AArch64 This fixes a regression where we don't have an instruction for pre Armv8.2-a to do a move of an fp16 value from a GP reg to a SIMD reg. This patch adds that pattern to movhf_aarch64 using a dup and only selectes it using a very low priority. This fixes an ICE at -O0. gcc/ 2018-06-20 Tamar Christina PR target/85769 * config/aarch64/aarch64.md (*movhf_aarch64): Add dup v0.4h pattern. gcc/testsuite/ 2018-06-20 Tamar Christina PR target/85769 * gcc.target/aarch64/f16_mov_immediate_3.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #10 from sameerad at gcc dot gnu.org --- > subus: >ldr w0, [w0] >add w0, w0, w0, lsr #16 >uxth w0, w0 >ret This is interesting way in which load store combining can be enhanced further. I will try to figure out if this can be integrated in my current implementation. Thanks Richard.
[Bug c++/86320] very long compilation time for std::array, 1024 * 1024>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86320 --- Comment #7 from Ulya --- Thank you, that was really fast!
