[Bug bootstrap/86450] Bootstrap failure due to -Wabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 Fritz Reese changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-10 CC||foreese at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Fritz Reese --- +1
[Bug bootstrap/86450] Bootstrap failure due to -Wabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Severity|normal |blocker
[Bug tree-optimization/86415] strlen() not folded for substrings within constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Implemented in r262522.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 86415, which changed state. Bug 86415 Summary: strlen() not folded for substrings within constant arrays https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/86415] strlen() not folded for substrings within constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415 --- Comment #4 from Martin Sebor --- Author: msebor Date: Tue Jul 10 00:02:36 2018 New Revision: 262528 URL: https://gcc.gnu.org/viewcvs?rev=262528=gcc=rev Log: PR tree-optimization/86415 - strlen() not folded for substrings within constant arrays gcc/testsuite/ChangeLog: * gcc.dg/strlenopt-53.c: New test. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-53.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #8 from Dominique d'Humieres --- > > The correct invocation of a GCC testsuite is "make -k check-blah", otherwise > > the recursive Make processes will stop on errors. > > > > Since when? I've been doing 'gmake check-fortran' and > 'gmake -j6 check-fortran' for more than 15 years. There > was never an error. This broke recently. Due to pr86417, there is a failure in the libgomp tests and make has to be used with -k.
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #7 from Steve Kargl --- On Mon, Jul 09, 2018 at 10:21:20PM +, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 > > --- Comment #6 from Eric Botcazou --- > > 'gmake -j6 check-fortran' has never died on an error > > like the one I've shown in the 15+ years that I've been > > contributing to GCC. Needing -k now, means someone has > > broken the build infrastructure. > > No, it's just https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01023.html > So, instead of using -k to pape over an error in the Makefile, what is wrong with the lines check-DEJAGNU: site.exp srcdir='$(srcdir)'; export srcdir; \ EXPECT=$(EXPECT); export EXPECT; \ runtest=$(RUNTEST); \ if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \ exit_status=0; l='$(DEJATOOL)'; for tool in $$l; do \ if $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) $(RUNTESTFLAGS); \ then :; else exit_status=1; fi; \ done; \ else echo "WARNING: could not find \`runtest'" 1>&2; :;\ fi; \ exit $$exit_status If the commands are command out, there are no errors. So, what is the above suppose to do other that cause 2 ERRORs in the build.
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #6 from Eric Botcazou --- > 'gmake -j6 check-fortran' has never died on an error > like the one I've shown in the 15+ years that I've been > contributing to GCC. Needing -k now, means someone has > broken the build infrastructure. No, it's just https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01023.html
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #5 from Steve Kargl --- On Mon, Jul 09, 2018 at 10:05:23PM +, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 > > --- Comment #4 from Eric Botcazou --- > > Since when? > > The dawn of time, see https://gcc.gnu.org/contribute.html#testing > 'gmake -j6 check-fortran' has never died on an error like the one I've shown in the 15+ years that I've been contributing to GCC. Needing -k now, means someone has broken the build infrastructure.
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #4 from Eric Botcazou --- > Since when? The dawn of time, see https://gcc.gnu.org/contribute.html#testing
[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417 --- Comment #11 from Thomas Koenig --- (In reply to janus from comment #10) > (In reply to janus from comment #9) > > The following patch seems to be sufficient to fix the regression: > > > ... however, it lacks a safety check for the existence of the ctor > expression. This variant regtests cleanly: > > > Index: gcc/fortran/expr.c > === > --- gcc/fortran/expr.c(revision 262509) > +++ gcc/fortran/expr.c(working copy) > @@ -4650,6 +4650,10 @@ gfc_generate_initializer (gfc_typespec *ts, bool g > } > } > > + /* Make sure that locus is set. */ > + if (ctor->expr && (!ctor->expr->where.nextc || !ctor->expr->where.lb)) > + ctor->expr->where = init->where; > + >gfc_constructor_append (>value.constructor, ctor); > } If possible, I would prefer to set the locus where it is generated, not conditionally later. Unfortunately, I cannot currently look into this due to PR 86450 :-( If I had a bootstrapping gcc, I would probably look at /* Fetch or generate an initializer for the component. */ tmp = component_initializer (comp, generate); and see if the locus is set correctly at that point, then (possibly) go back to component_initializer to see where this is missing.
[Bug bootstrap/86450] New: Bootstrap failure due to -Wabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 Bug ID: 86450 Summary: Bootstrap failure due to -Wabi Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Created attachment 44368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44368=edit config.log from failed build Recent trunk at r262520 failed to build on, it was configured with $ CC=/usr/bin/gcc CXX=/usr/bin/g++ ../trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran --enable-maintainer-mode for x86_64-pc-linux-gnu and then built with $ make -j8 which led to the errors ibtool: compile: /home/ig25/Gcc/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/ig25/Gcc/trunk-bin/./gcc -nostdinc++ -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/ig25/x86_64-pc-linux-gnu/bin/ -B/home/ig25/x86_64-pc-linux-gnu/lib/ -isystem /home/ig25/x86_64-pc-linux-gnu/include -isystem /home/ig25/x86_64-pc-linux-gnu/sys-include -fno-checking -I/home/ig25/Gcc/trunk/libstdc++-v3/../libgcc -I/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/ig25/Gcc/trunk/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=bad_array_length.lo -g -O2 -D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/libsupc++/bad_array_length.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o bad_array_length.o cc1plus: error: -Wabi won't warn about anything [-Werror=abi] cc1plus: error: -Wabi won't warn about anything [-Werror=abi] cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 libtool: compile: /home/ig25/Gcc/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/ig25/Gcc/trunk-bin/./gcc -nostdinc++ -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/ig25/x86_64-pc-linux-gnu/bin/ -B/home/ig25/x86_64-pc-linux-gnu/lib/ -isystem /home/ig25/x86_64-pc-linux-gnu/include -isystem /home/ig25/x86_64-pc-linux-gnu/sys-include -fno-checking -I/home/ig25/Gcc/trunk/libstdc++-v3/../libgcc -I/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/ig25/Gcc/trunk/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=bad_array_new.lo -g -O2 -D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/libsupc++/bad_array_new.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o bad_array_new.o cc1plus: error: -Wabi won't warn about anything [-Werror=abi] cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 libtool: compile: /home/ig25/Gcc/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/ig25/Gcc/trunk-bin/./gcc -nostdinc++ -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/ig25/x86_64-pc-linux-gnu/bin/ -B/home/ig25/x86_64-pc-linux-gnu/lib/ -isystem /home/ig25/x86_64-pc-linux-gnu/include -isystem /home/ig25/x86_64-pc-linux-gnu/sys-include -fno-checking -I/home/ig25/Gcc/trunk/libstdc++-v3/../libgcc -I/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/ig25/Gcc/trunk/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -Werror -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=bad_typeid.lo -g -O2 -D_GNU_SOURCE -c ../../../../trunk/libstdc++-v3/libsupc++/bad_typeid.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o bad_typeid.o libtool: compile: /home/ig25/Gcc/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/ig25/Gcc/trunk-bin/./gcc -nostdinc++ -L/home/ig25/Gcc/trunk-bin/x86_64-pc-linux-gnu/libstdc++-v3/src
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 86428, which changed state. Bug 86428 Summary: strlen of const array initialized with a string of the same length not folded https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86428 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/86428] strlen of const array initialized with a string of the same length not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86428 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Committed in r262522.
[Bug middle-end/77357] strlen of constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Committed in r262522.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 77357, which changed state. Bug 77357 Summary: strlen of constant strings not folded https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/77357] strlen of constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357 --- Comment #6 from Martin Sebor --- Author: msebor Date: Mon Jul 9 20:33:48 2018 New Revision: 262522 URL: https://gcc.gnu.org/viewcvs?rev=262522=gcc=rev Log: PR middle-end/77357 - strlen of constant strings not folded gcc/ChangeLog: PR middle-end/77357 PR middle-end/86428 * builtins.c (c_strlen): Avoid out-of-bounds warnings when accessing implicitly initialized array elements. * expr.c (string_constant): Handle string initializers of character arrays within aggregates. * gimple-fold.c (fold_array_ctor_reference): Add argument. Store element offset. As a special case, handle zero size. (fold_nonarray_ctor_reference): Same. (fold_ctor_reference): Add argument. Store subobject offset. * gimple-fold.h (fold_ctor_reference): Add argument. gcc/testsuite/ChangeLog: PR middle-end/77357 * gcc.dg/strlenopt-49.c: New test. * gcc.dg/strlenopt-50.c: New test. * gcc.dg/strlenopt-51.c: New test. * gcc.dg/strlenopt-52.c: New test. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-49.c trunk/gcc/testsuite/gcc.dg/strlenopt-50.c trunk/gcc/testsuite/gcc.dg/strlenopt-51.c trunk/gcc/testsuite/gcc.dg/strlenopt-52.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/fold-const.c trunk/gcc/fold-const.h trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c
[Bug tree-optimization/86428] strlen of const array initialized with a string of the same length not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86428 --- Comment #3 from Martin Sebor --- Author: msebor Date: Mon Jul 9 20:33:48 2018 New Revision: 262522 URL: https://gcc.gnu.org/viewcvs?rev=262522=gcc=rev Log: PR middle-end/77357 - strlen of constant strings not folded gcc/ChangeLog: PR middle-end/77357 PR middle-end/86428 * builtins.c (c_strlen): Avoid out-of-bounds warnings when accessing implicitly initialized array elements. * expr.c (string_constant): Handle string initializers of character arrays within aggregates. * gimple-fold.c (fold_array_ctor_reference): Add argument. Store element offset. As a special case, handle zero size. (fold_nonarray_ctor_reference): Same. (fold_ctor_reference): Add argument. Store subobject offset. * gimple-fold.h (fold_ctor_reference): Add argument. gcc/testsuite/ChangeLog: PR middle-end/77357 * gcc.dg/strlenopt-49.c: New test. * gcc.dg/strlenopt-50.c: New test. * gcc.dg/strlenopt-51.c: New test. * gcc.dg/strlenopt-52.c: New test. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-49.c trunk/gcc/testsuite/gcc.dg/strlenopt-50.c trunk/gcc/testsuite/gcc.dg/strlenopt-51.c trunk/gcc/testsuite/gcc.dg/strlenopt-52.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/fold-const.c trunk/gcc/fold-const.h trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c
[Bug target/86449] New: GCC 8 compiler generates slower code for spec 2006 calculix on a power9 using -mcpu=power9 than using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86449 Bug ID: 86449 Summary: GCC 8 compiler generates slower code for spec 2006 calculix on a power9 using -mcpu=power9 than using -mcpu=power8 Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- I ran spec 2006 on a DD2.2 power9, and I noticed the GCC 8.x branch (subversion id 26248) generated slower code for calculix when compiled with a -mcpu=power9 option instead of -mcpu=power8. Note, the trunk actually generates 2% faster code for -mcpu=power9 than for -mcpu=power8. This issue is only a regression on the GCC 8 branch.
[Bug target/86448] New: GCC 9 compiler generates slower code for spec 2006 milc on a power9 using -mcpu=power9 than using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86448 Bug ID: 86448 Summary: GCC 9 compiler generates slower code for spec 2006 milc on a power9 using -mcpu=power9 than using -mcpu=power8 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- I built spec 2006 on a DD2.2 power9 and ran it. I noticed that the milc benchmark was 2% slower using either the trunk or the GCC 8 branch (subversion id 262483) if I compiled the code using -mcpu=power9 compared to -mcpu=power8.
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #3 from Steve Kargl --- On Mon, Jul 09, 2018 at 07:33:48PM +, sgk at troutmask dot apl.washington.edu wrote: > > gmake[4]: *** [Makefile:306: check-DEJAGNU] Error 1 > gmake[4]: Leaving directory > '/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp/testsuite' > gmake[3]: *** [Makefile:350: check-am] Error 2 > gmake[3]: Leaving directory > '/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp > If I comment out lines 306-316 in ./x86_64-unknown-freebsd12.0/libgomp/testsuite/Makefile check-DEJAGNU: site.exp # srcdir='$(srcdir)'; export srcdir; \ # EXPECT=$(EXPECT); export EXPECT; \ # runtest=$(RUNTEST); \ # if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \ # exit_status=0; l='$(DEJATOOL)'; for tool in $$l; do \ # if $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) $(RUNTESTFLAGS); \ # then :; else exit_status=1; fi; \ # done; \ # else echo "WARNING: could not find \`runtest'" 1>&2; :;\ # fi; \ # exit $$exit_status gmake -j6 check-fortran completes with === gfortran Summary === # of expected passes8017 # of expected failures 3 # of unsupported tests 24 /safe/sgk/gcc/obj/gcc/gfortran version 9.0.0 20180709 (experimental) (GCC) gmake[2]: Leaving directory '/safe/sgk/gcc/obj/gcc' gmake[1]: Leaving directory '/safe/sgk/gcc/obj/gcc' as I expect. This check is bogus.
[Bug libstdc++/86447] New: gcc 9.0 from r262456 can't build cross compiler for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86447 Bug ID: 86447 Summary: gcc 9.0 from r262456 can't build cross compiler for mingw-w64 target Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mateuszb at poczta dot onet.pl Target Milestone: --- Target: mingw-w64 >From r262456 when I compile cross compiler (in Ubuntu) for mingw-w64 target there is a bug: libtool: compile: /home/ma/m/build/bc_gcc/./gcc/xgcc -shared-libgcc -B/home/ma/m/build/bc_gcc/./gcc -nostdinc++ -L/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src -L/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ma/m/cross/x86_64-w64-mingw32/lib -L/home/ma/m/cross/mingw/lib -isystem /home/ma/m/cross/x86_64-w64-mingw32/include -isystem /home/ma/m/cross/mingw/include -B/home/ma/m/cross/x86_64-w64-mingw32/bin/ -B/home/ma/m/cross/x86_64-w64-mingw32/lib/ -isystem /home/ma/m/cross/x86_64-w64-mingw32/include -isystem /home/ma/m/cross/x86_64-w64-mingw32/sys-include -I/home/ma/m/source/gcc-9/libstdc++-v3/../libgcc -I/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/home/ma/m/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/include -I/home/ma/m/source/gcc-9/libstdc++-v3/libsupc++ -std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c /home/ma/m/source/gcc-9/libstdc++-v3/src/c++11/cow-stdexcept.cc -o cow-stdexcept.o cc1plus: warning: -Wabi won't warn about anything [-Wabi] cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, which is also used by default cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 /home/ma/m/source/gcc-9/libstdc++-v3/src/c++11/cow-stdexcept.cc:67:3: error: function 'std::logic_error::logic_error(std::logic_error&&)' defaulted on its redeclaration with an exception-specification that differs from the implicit exception-specification '' logic_error::logic_error(logic_error&& e) noexcept = default; ^~~ /home/ma/m/source/gcc-9/libstdc++-v3/src/c++11/cow-stdexcept.cc:79:3: error: function 'std::runtime_error::runtime_error(std::runtime_error&&)' defaulted on its redeclaration with an exception-specification that differs from the implicit exception-specification '' runtime_error::runtime_error(runtime_error&& e) noexcept = default; ^ Makefile:562: recipe for target 'cow-stdexcept.lo' failed make[5]: *** [cow-stdexcept.lo] Error 1 The bug is in phase when new compiled gcc is trying to compile libraries.
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 --- Comment #2 from Steve Kargl --- On Mon, Jul 09, 2018 at 07:20:02PM +, ebotcazou at gcc dot gnu.org wrote: > > The correct invocation of a GCC testsuite is "make -k check-blah", otherwise > the recursive Make processes will stop on errors. > Since when? I've been doing 'gmake check-fortran' and 'gmake -j6 check-fortran' for more than 15 years. There was never an error. This broke recently. I just did a bootstrap of the 8-branch. 'gmake -j6 check-fortran' completes without an error. The last few line are === gfortran Summary === # of expected passes6413 # of expected failures 18 # of unsupported tests 2 /safe/sgk/gcc/obj8/gcc/gfortran version 8.1.1 20180709 (GCC) gmake[2]: Leaving directory '/safe/sgk/gcc/obj8/gcc' gmake[1]: Leaving directory '/safe/sgk/gcc/obj8/gcc' Something is broken with trunk. These do not occur on the 8-branch. gmake[4]: *** [Makefile:306: check-DEJAGNU] Error 1 gmake[4]: Leaving directory '/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp/testsuite' gmake[3]: *** [Makefile:350: check-am] Error 2 gmake[3]: Leaving directory '/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp
[Bug testsuite/86446] 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Eric Botcazou --- The correct invocation of a GCC testsuite is "make -k check-blah", otherwise the recursive Make processes will stop on errors.
[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
--- Comment #2 from Uroš Bizjak ---
Here is what happens:
compare operators in (insn 66) are substituted with their defs from (insn 64)
and (insn 14). The CC mode is calculated from SELECT_CC_MODE, which really
returns CCCmode. The flags reg clobber is substituted with the compare, and
insn then matches {*adddi3_cc_overflow_1}.
Unfortunately, the compare is not correct. %rax from (insn 14) is already
updated, and should not be compared with its previous value from (insn 64).
[Bug testsuite/86446] New: 'gmake check-fortran' broken in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
Bug ID: 86446
Summary: 'gmake check-fortran' broken in libgomp
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
=== libgomp Summary ===
# of expected passes4021
# of unexpected failures2
# of unsupported tests 134
gmake[4]: *** [Makefile:306: check-DEJAGNU] Error 1
gmake[4]: Leaving directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp/testsuite'
gmake[3]: *** [Makefile:350: check-am] Error 2
gmake[3]: Leaving directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp/testsuite'
gmake[3]: Entering directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp'
gmake DO=all multi-do # gmake
gmake[4]: Entering directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp'
if [ -z "" ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd ../../../gcc/libgomp; ${PWDCMD-pwd}`/; export srcrootpre; \
lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler="/safe/sgk/gcc/obj/./gcc/xgcc -B/safe/sgk/gcc/obj/./gcc/
-B/safe/sgk/work/x/x86_64-unknown-freebsd12.0/bin/
-B/safe/sgk/work/x/x86_64-unknown-freebsd12.0/lib/ -isystem
/safe/sgk/work/x/x86_64-unknown-freebsd12.0/include -isystem
/safe/sgk/work/x/x86_64-unknown-freebsd12.0/sys-include "; \
for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; gmake \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS=" ${flags}" \
FCFLAGS="-L. -Wall -L../libgfortran ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/safe/sgk/work/x" \
exec_prefix="/safe/sgk/work/x" \
GOCFLAGS="-O2 -g ${flags}" \
CXXFLAGS="-g -O2 ${flags}" \
LIBCFLAGS="-g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
INSTALL="/usr/bin/install -c" \
INSTALL_DATA="/usr/bin/install -c -m 644" \
INSTALL_PROGRAM="/usr/bin/install -c" \
INSTALL_SCRIPT="/usr/bin/install -c" \
all); then \
true; \
else \
exit 1; \
fi; \
else true; \
fi; \
fi; \
done; \
fi
gmake[4]: Leaving directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp'
:
:
:
gmake[3]: Leaving directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp'
gmake[2]: *** [Makefile:904: check-recursive] Error 1
gmake[2]: Leaving directory
'/safe/sgk/gcc/obj/x86_64-unknown-freebsd12.0/libgomp'
gmake[1]: *** [Makefile:21394: check-target-libgomp] Error 2
gmake[1]: Leaving directory '/safe/sgk/gcc/obj'
gmake: *** [Makefile:22584: check-target-libgomp-fortran] Error 2
[Bug testsuite/86445] New: [9 regression] Missing warning for test case gcc/testsuite/gcc.dg/pr84100.c starting with r262513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86445 Bug ID: 86445 Summary: [9 regression] Missing warning for test case gcc/testsuite/gcc.dg/pr84100.c starting with r262513 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr84100.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o pr84100.s (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/pr84100.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o pr84100.s FAIL: gcc.dg/pr84100.c (test for warnings, line 11) PASS: gcc.dg/pr84100.c (test for excess errors) testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 It is not generating this warning now: home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr84100.c:11:1: warning: bad option '-falign-loops=16' to attribute 'optimize' [-Wattributes] Note the test case was updated in r262375 just last week.
[Bug c++/86440] -Wignored-qualifiers diagnostic highlights wrong token with pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-09
Ever confirmed|0 |1
--- Comment #1 from David Malcolm ---
Thanks for filing this bug.
Confirmed with trunk, gcc-8, and gcc-7.
gcc-6 and earlier put both warnings on the close-parentheses:
/tmp/test.cc:1:13: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
int const f() { return 0; }
^
/tmp/test.cc:3:15: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
int * const g() { return 0; }
^
[Bug fortran/86421] OpenMP declare simd linear ref in module causes gfortran to bail out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86421 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 44367 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44367=edit gcc9-pr86421.patch Untested fix.
[Bug target/86444] New: [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86444 Bug ID: 86444 Summary: [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: craig.topper at gmail dot com Target Milestone: --- It looks like gcc does not match the behavior of the most recent versions of icc, clang, and MSVC with respect to the behavior or NaNs in the COMI intrinsics. The other compilers are all returning 0 when the compare result is unordered. As can be seen here: https://godbolt.org/g/xxEKqg Clang changed to this behavior in version 3.9. According to this comment from https://bugs.llvm.org/show_bug.cgi?id=28510#c10, the original icc behavior was the same as gcc’s current behavior, but it was changed at least 10 years ago.
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #13 from rguenther at suse dot de --- On July 9, 2018 5:40:31 PM GMT+02:00, "boris.staletic at gmail dot com" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 > >--- Comment #12 from Boris Staletic >--- >If you're wondering about clang, it hangs too, but doesn't hog memory. > >> That's to be expected when it runs into swap. > >Anything else I should try? Nothing off my head.
[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86426 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-09 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, but even 4.6 ICEs for me.
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #12 from Boris Staletic --- If you're wondering about clang, it hangs too, but doesn't hog memory. > That's to be expected when it runs into swap. Anything else I should try?
[Bug lto/86442] Wrong error: global register variable follows a function definition when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Indeed, I think the build system should be passing -fno-lto for such translation units, as their ABI is different from the rest. I'm not sure limiting the inliner is enough, there's also IPA-RA and it's not obviously safe w.r.t global-reg-var differences. If there's a desire to support such usage "seamlessly", I'd really like to see the same solution for this and toplevel asms: making such input translation unit one LTO partition (i.e. not splitting or merging it with anything else).
[Bug c++/86397] [7/8/9 Regression] g++ ICE at on valid code in nothrow_spec_p, at cp/except.c:1158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86397 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-09 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Started with r244575.
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #11 from rguenther at suse dot de --- On July 9, 2018 5:18:40 PM GMT+02:00, "boris.staletic at gmail dot com" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 > >--- Comment #10 from Boris Staletic >--- >Running "g++ -S -fno-exceptions CodePoint.cpp" didn't run into OOM >killer, but >gcc still hanged. The memory usage at maximum was 15.6GB. What I find >strange >is that "htop" reported the g++ process as dead most of the time and >the CPU >usage was 20% to 25% (or less) while that was happening. That's to be expected when it runs into swap. GCC is bad at keeping the active memory set small because it uses garbage collection and the mark and sweep phase pages in everything...
[Bug lto/86442] Wrong error: global register variable follows a function definition when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
--- Comment #1 from Jan Hubicka ---
> Following wrong error is printed with LTO:
>
> $ cat global.cpp
> register int a __asm__("r12");
>
> class b {
> public:
> b();
> };
>
> b c;
>
> int main() { a = 3; }
>
> $ g++ global.cpp -O2 -flto
> global.cpp: In function ‘main’:
> global.cpp:1:14: error: global register variable follows a function definition
> register int a __asm__("r12");
> ^
> lto-wrapper: fatal error: g++ returned 1 exit status
> compilation terminated.
> /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
> error:
> lto-wrapper failed
> collect2: error: ld returned 1 exit status
Global register variables are not really working with LTO (because they should
be part of the function context since they may differ across units).
We could try to fix them for gcc 9. I was thinking a bit about it, but it
would
need to attach the information somewhere into optimization node and make
inliner
to not inline across different globally allocated registers.
It is overall questionable how global registers should interact with the symbol
table.
Honza
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #10 from Boris Staletic --- Running "g++ -S -fno-exceptions CodePoint.cpp" didn't run into OOM killer, but gcc still hanged. The memory usage at maximum was 15.6GB. What I find strange is that "htop" reported the g++ process as dead most of the time and the CPU usage was 20% to 25% (or less) while that was happening.
[Bug c++/86443] New: ICEs on #pragma omp distribute parallel for with class iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86443
Bug ID: 86443
Summary: ICEs on #pragma omp distribute parallel for with class
iterators
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
// { dg-do run }
// { dg-additional-options "-std=c++17" }
typedef __PTRDIFF_TYPE__ ptrdiff_t;
extern "C" void abort ();
#pragma omp declare target
template
class I
{
public:
typedef ptrdiff_t difference_type;
I ();
~I ();
I (T *);
I (const I &);
T * ();
T *operator -> ();
T [] (const difference_type &) const;
I = (const I &);
I ++ ();
I operator ++ (int);
I -- ();
I operator -- (int);
I += (const difference_type &);
I -= (const difference_type &);
I operator + (const difference_type &) const;
I operator - (const difference_type &) const;
template friend bool operator == (I &, I &);
template friend bool operator == (const I &, const I &);
template friend bool operator < (I &, I &);
template friend bool operator < (const I &, const I &);
template friend bool operator <= (I &, I &);
template friend bool operator <= (const I &, const I &);
template friend bool operator > (I &, I &);
template friend bool operator > (const I &, const I &);
template friend bool operator >= (I &, I &);
template friend bool operator >= (const I &, const I &);
template friend typename I::difference_type operator - (I
&, I &);
template friend typename I::difference_type operator - (const
I &, const I &);
template friend I operator + (typename I::difference_type
, const I &);
private:
T *p;
};
template I::I () : p (0) {}
template I::~I () {}
template I::I (T *x) : p (x) {}
template I::I (const I ) : p (x.p) {}
template T ::operator * () { return *p; }
template T *I::operator -> () { return p; }
template T ::operator [] (const difference_type ) const {
return p[x]; }
template I ::operator = (const I ) { p = x.p; return
*this; }
template I ::operator ++ () { ++p; return *this; }
template I I::operator ++ (int) { return I (p++); }
template I ::operator -- () { --p; return *this; }
template I I::operator -- (int) { return I (p--); }
template I ::operator += (const difference_type ) { p +=
x; return *this; }
template I ::operator -= (const difference_type ) { p -=
x; return *this; }
template I I::operator + (const difference_type ) const {
return I (p + x); }
template I I::operator - (const difference_type ) const {
return I (p - x); }
template bool operator == (I , I ) { return x.p == y.p;
}
template bool operator == (const I , const I ) { return
x.p == y.p; }
template bool operator != (I , I ) { return !(x == y); }
template bool operator != (const I , const I ) { return
!(x == y); }
template bool operator < (I , I ) { return x.p < y.p; }
template bool operator < (const I , const I ) { return
x.p < y.p; }
template bool operator <= (I , I ) { return x.p <= y.p;
}
template bool operator <= (const I , const I ) { return
x.p <= y.p; }
template bool operator > (I , I ) { return x.p > y.p; }
template bool operator > (const I , const I ) { return
x.p > y.p; }
template bool operator >= (I , I ) { return x.p >= y.p;
}
template bool operator >= (const I , const I ) { return
x.p >= y.p; }
template typename I::difference_type operator - (I , I
) { return x.p - y.p; }
template typename I::difference_type operator - (const I ,
const I ) { return x.p - y.p; }
template I operator + (typename I::difference_type x, const
I ) { return I (x + y.p); }
template
class J
{
public:
J(const I , const I ) : b (x), e (y) {}
const I ();
const I ();
private:
I b, e;
};
template const I ::begin () { return b; }
template const I ::end () { return e; }
int a[2000];
int results[2000];
template
void
baz (I )
{
if (*i < 0 || *i >= 2000)
abort ();
results[*i]++;
}
void
baz (int i)
{
if (i < 0 || i >= 2000)
abort ();
results[i]++;
}
void
qux (I )
{
if (*i != 1931)
abort ();
}
void
f1 (J j)
{
#pragma omp distribute parallel for default(none)
for (I i = j.begin (); i < j.end (); i += 3)
baz (*i);
}
void
f2 (J j)
{
I i;
#pragma omp distribute parallel for default(none)
for (i = j.begin (); i < j.end (); ++i)
baz (*i);
}
template
void
f3 (J j)
{
#pragma omp distribute parallel for default(none)
for (I i = j.begin (); i < j.end (); i += 6)
baz (*i);
}
template
void
f4 (J j)
{
I i;
#pragma omp distribute parallel for default(none)
for (i = j.begin (); i < j.end (); i += 9)
baz (*i);
}
template
void
f5 (J j)
{
#pragma omp distribute parallel for default(none)
for (I i = j.begin (); i < j.end (); i += 4)
baz (*i);
}
template
void
f6 (J j)
{
I i;
#pragma omp distribute parallel for default(none)
for (i = j.begin (); i < j.end (); i
[Bug c++/86441] instantiate_class_template() unable to re-execute constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441 --- Comment #1 from Boris Kolpackov --- Created attachment 44366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44366=edit Test case that shows the problem if compiled with ODB For the record, a test case that triggers the error if compiled with ODB that uses GCC 8.
[Bug lto/86442] New: Wrong error: global register variable follows a function definition when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
Bug ID: 86442
Summary: Wrong error: global register variable follows a
function definition when using LTO
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Following wrong error is printed with LTO:
$ cat global.cpp
register int a __asm__("r12");
class b {
public:
b();
};
b c;
int main() { a = 3; }
$ g++ global.cpp -O2 -flto
global.cpp: In function ‘main’:
global.cpp:1:14: error: global register variable follows a function definition
register int a __asm__("r12");
^
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug c++/86441] New: instantiate_class_template() unable to re-execute constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
Bug ID: 86441
Summary: instantiate_class_template() unable to re-execute
constexpr function
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
I have a GCC plugin (ODB) that calls instantiate_class_template() to
"post-instantiate" some types that haven't been instantiated during parsing.
The code is pretty much identical to what complete_type() does to class
templates. This has been working pretty well since the GCC 4.5 days.
This also generally works in GCC 8 except it seems when the instantiation
requires re-execution of a constexpr function. Below are the details of a
specific example of this situation.
The plugin tries to instantiate a type that is declared like this:
#include
#include
using strmap = std::map;
This works fine unless I have a different instantiation of std::map:
#include
#include
using intmap = std::map;
struct foo
{
intmap m;
};
using strmap = std::map;
In this case I get (during the call to instantiate_class_template(strmap)):
/usr/include/c++/8/bits/stl_tree.h: In instantiation of ‘class
std::_Rb_tree, std::pair, std::__cxx11::basic_string >,
std::_Select1st,
std::__cxx11::basic_string > >,
std::less >, std::allocator, std::__cxx11::basic_string > > >’:
/usr/include/c++/8/bits/stl_map.h:151:17: required from ‘class
std::map, std::__cxx11::basic_string >’
test.hxx:11:16: required from here
/usr/include/c++/8/bits/stl_tree.h:452:21: error: non-constant condition for
static assertion
static_assert(__is_invocable<_Compare&, const _Key&, const _Key&>{},
^
/usr/include/c++/8/bits/stl_tree.h:452: confused by earlier errors, bailing out
If I change stl_tree.h:452 from '__is_invocable<_Compare&, const _Key&, const
_Key&>{}' to '__is_invocable<_Compare&, const _Key&, const _Key&>::value', then
the error goes away. To me this suggests it has something to do we re-executing
(it has already been executed when instantiating intmap) of a constexpr
function (operator bool() in true_type).
Providing a reproducer is challenging since the instantiation is triggered by a
plugin. But let me know if I need to provide any additional information or
test/verify a fix.
[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||ebotcazou at gcc dot gnu.org
[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-09
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ---
Looks like postreload cmp elimitation pass is at fault.
It converts:
(insn 64 63 76 2 (parallel [
(set (reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])
(plus:DI (reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])
(const_int 5 [0x5])))
(clobber (reg:CC 17 flags))
]) "pr86438.c":17 232 {*adddi_1}
(nil))
(insn 76 64 77 2 (set (reg:DI 4 si [orig:88 _2 ] [88])
(const_int 0 [0])) "pr86438.c":18 85 {*movdi_internal}
(nil))
(insn 77 76 14 2 (set (reg:DI 5 di [ _2+8 ])
(const_int 0 [0])) "pr86438.c":18 85 {*movdi_internal}
(nil))
(insn 14 77 15 2 (set (reg:DI 4 si [orig:88 _2 ] [88])
(reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])) "pr86438.c":18 85
{*movdi_internal}
(nil))
(insn 15 14 66 2 (set (reg:DI 5 di [ _2+8 ])
(const_int 0 [0])) "pr86438.c":18 85 {*movdi_internal}
(nil))
(insn 66 15 67 2 (set (reg:CC 17 flags)
(compare:CC (reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])
(reg:DI 4 si [orig:88 _2 ] [88]))) "pr86438.c":18 12 {*cmpdi_1}
(nil))
(note 67 66 78 2 NOTE_INSN_DELETED)
(insn 78 67 79 2 (set (reg:QI 2 cx [orig:96 _11+8 ] [96])
(ltu:QI (reg:CC 17 flags)
(const_int 0 [0]))) "pr86438.c":18 700 {*setcc_qi}
(nil))
to:
(insn 64 63 76 2 (parallel [
(set (reg:CCC 17 flags)
(compare:CCC (plus:DI (reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])
(const_int 5 [0x5]))
(reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])))
(set (reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])
(plus:DI (reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])
(const_int 5 [0x5])))
]) "pr86438.c":17 346 {*adddi3_cc_overflow_1}
(nil))
(insn 76 64 77 2 (set (reg:DI 4 si [orig:88 _2 ] [88])
(const_int 0 [0])) "pr86438.c":18 85 {*movdi_internal}
(nil))
(insn 77 76 14 2 (set (reg:DI 5 di [ _2+8 ])
(const_int 0 [0])) "pr86438.c":18 85 {*movdi_internal}
(nil))
(insn 14 77 15 2 (set (reg:DI 4 si [orig:88 _2 ] [88])
(reg:DI 0 ax [orig:94 iftmp.0_9 ] [94])) "pr86438.c":18 85
{*movdi_internal}
(nil))
(insn 15 14 67 2 (set (reg:DI 5 di [ _2+8 ])
(const_int 0 [0])) "pr86438.c":18 85 {*movdi_internal}
(nil))
(note 67 15 78 2 NOTE_INSN_DELETED)
(insn 78 67 79 2 (set (reg:QI 2 cx [orig:96 _11+8 ] [96])
(ltu:QI (reg:CCC 17 flags)
(const_int 0 [0]))) "pr86438.c":18 700 {*setcc_qi}
(nil))
Please note that (insn 66) is deleted and (insn 64) gets converted to an insn
that sets flags reg in CCCmode (where only carry flag is valid). The original
sequence sets flags reg in CCmode (where all flags are valid), so these two
sequences are not identical.
Adding -fno-compare-elim fixes the test.
[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |8.3
[Bug libstdc++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC||jason at gcc dot gnu.org,
||redi at gcc dot gnu.org
Component|c++ |libstdc++
--- Comment #9 from Richard Biener ---
Thanks for confirming the crash reason.
So I wonder, quoting a small testcase:
#include
struct RawCodePoint {
const std::string original;
const std::string normal;
const std::string folded_case;
const std::string swapped_case;
bool is_letter;
bool is_punctuation;
bool is_uppercase;
unsigned char break_property;
unsigned char combining_class;
};
void foo() {
static const RawCodePoint code_points[] = {
{"\x00","\x00","\x00","\x00",0,0,0,3,0},
{"^A","^A","^A","^A",0,0,0,3,0},
{"^B","^B","^B","^B",0,0,0,3,0}
};
}
why with the new std::string and its small string optimization we cannot
"constexpr" the constructor (not sure what clang does here).
I suppose one issue is that the C++ FE arranges for the constructors to
throw and thus emits cleanups for others.
But in the end the testcase doesn't look unreasonable and we should do
better (constexpr evaluation should be able to tell whether we'll throw
as well).
So, another question to the reporter - does -fno-exceptions help
for your original testcase (the preprocessed one doesn't like
-fno-exceptions)?
[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 --- Comment #8 from Boris Staletic --- > ulimit -s unlimited After running that command and enabling swap, for a total of 16GB available memory, until about 5 minute mark, cc1plus was consuming >4GB. After about five minute mark, cc1plus started consuming memory rapidly, and in about a minute or so, it consumed all 16GB. The end result is OOM killer stopping cc1plus.
[Bug c++/86440] New: -Wignored-qualifiers diagnostic highlights wrong token with pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
Bug ID: 86440
Summary: -Wignored-qualifiers diagnostic highlights wrong token
with pointer
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
$ cat a.cc
int const f() { return 0; }
int * const g() { return 0; }
$ g++ a.cc -c -Wignored-qualifiers
a.cc:1:5: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
int const f() { return 0; }
^
a.cc:3:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
int * const g() { return 0; }
^~~
[Bug c++/82711] -Wignored-qualifiers could be moved into -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82711
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment #4 from nightstrike ---
It looks to me like this has been done, at least for g++ 8.1.0:
$ g++ a.cc -c
$ g++ a.cc -c -Wextra
a.cc:1:5: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
int const f() { return 0; }
^
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #28 from Oleg Endo --- (In reply to Eric Gallager from comment #27) > (In reply to Oleg Endo from comment #26) > > Author: olegendo > > Date: Mon Jan 26 23:56:05 2015 > > New Revision: 220144 Well, it fixed some of the cases mentioned in this PR, but not all. It's quite a broad issue actually.
[Bug c++/86439] New: CTAD with deleted copy constructor fails due to deduction-guide taking by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86439
Bug ID: 86439
Summary: CTAD with deleted copy constructor fails due to
deduction-guide taking by value
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from: https://stackoverflow.com/q/51244047/2069064
struct NC {
NC() = default;
NC(NC const&) = delete;
NC& operator=(NC const&) = delete;
};
template
struct C {
C(NC const&);
};
C(NC) -> C<0>;
int main() {
NC nc;
C c(nc);
}
clang accepts.
gcc rejects this program with:
: In function 'int main()':
:16:11: error: class template argument deduction failed:
C c(nc);
^
:16:11: error: use of deleted function 'NC::NC(const NC&)'
:3:5: note: declared here
NC(NC const&) = delete;
^~
:12:1: note: initializing argument 1 of 'C(NC)-> C<0>'
C(NC) -> C<0>;
^
But nowhere do we need to copy NC here. CTAD doesn't require invoking the
function, just picking the best viable candidate. And once we pick C<0>,
actually constructing a C<0> is fine since it doesn't require a copy.
[Bug rtl-optimization/86438] New: [8/9 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438 Bug ID: 86438 Summary: [8/9 Regression] wrong code at -Os Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 44365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44365=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -Os testcase.c $ ./a.out Aborted Diff between -O2 -> -Os shows: @@ -77,15 +76,15 @@ # testcase.c:13: u32 f = __builtin_sub_overflow_p (d, (u128) d, (u64)0); mov ebx, 0 # _2, # testcase.c:12: u64 d = (g ? 5 : 4); - setne al #, iftmp.0_9 - movzx eax, al # iftmp.0_9, iftmp.0_9 - add rax, 4 # iftmp.0_9, + cmp rax, 1 # tmp100, + sbb rax, rax# iftmp.0_9 + add rax, 5 # iftmp.0_9, # testcase.c:13: u32 f = __builtin_sub_overflow_p (d, (u128) d, (u64)0); mov rcx, rax# _2, iftmp.0_9 setcal #, _11 The - (-O2) never sets CF (thus the last setc always sets al=0). The + (-Os) set CF if g==0 (thus the last setc sets al=(g==0)). The __builtin_sub_overflow_p() in fact never overflows, because it does (u64)d-(u128)d == 0 in all cases. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-262509-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-262509-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix gcc version 9.0.0 20180709 (experimental) (GCC)
[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) > The following patch seems to be sufficient to fix the regression: ... however, it lacks a safety check for the existence of the ctor expression. This variant regtests cleanly: Index: gcc/fortran/expr.c === --- gcc/fortran/expr.c (revision 262509) +++ gcc/fortran/expr.c (working copy) @@ -4650,6 +4650,10 @@ gfc_generate_initializer (gfc_typespec *ts, bool g } } + /* Make sure that locus is set. */ + if (ctor->expr && (!ctor->expr->where.nextc || !ctor->expr->where.lb)) + ctor->expr->where = init->where; + gfc_constructor_append (>value.constructor, ctor); }
[Bug c/86420] [9 regression] nextafter(0x1p-1022,0) is constant folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86420 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jul 9 10:56:47 2018 New Revision: 262517 URL: https://gcc.gnu.org/viewcvs?rev=262517=gcc=rev Log: PR c/86420 * real.c (real_nextafter): Return true if result is denormal. * gcc.dg/nextafter-1.c (TEST): Adjust the tests that expect denormals to be returned and when first argument is not 0, so that they don't do anything for NEED_EXC or NEED_ERRNO. Modified: trunk/gcc/ChangeLog trunk/gcc/real.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/nextafter-1.c
[Bug tree-optimization/86434] early string folding defeats strlen optimization and -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86434
--- Comment #2 from Richard Biener ---
Are these examples from real-world code? Because I can create examples where
early folding is necessary as well...
It's really not an easy black-and-white decision.
Consider
void f (int i)
{
if (__builtin_strlen ([i]) != 3 - i)
{
... large code ...
}
}
void g ()
{
f (1);
}
where not folding and eliding the conditionaly will prevent inlining from
happening.
The usual "solution" is to do value-range analysis and folding at the same
time - thus avoiding pass inter-dependences by just having a single pass.
[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from Richard Biener --- Yeah, so there's into-SSA for example: #63 0x01368cd6 in prepare_block_for_update ( bb=, insert_phi_p=true) at /space/rguenther/src/svn/gcc-8-branch/gcc/tree-into-ssa.c:2677 2677prepare_block_for_update (son, insert_phi_p); (gdb) l 2672 2673 /* Now visit all the blocks dominated by BB. */ 2674 for (son = first_dom_son (CDI_DOMINATORS, bb); 2675 son; 2676 son = next_dom_son (CDI_DOMINATORS, son)) 2677prepare_block_for_update (son, insert_phi_p); and there are many more in the tree. So, can you check your stack ulimit and see if raising it solves the issue for you (memory usage is still very high though).
[Bug c++/86422] G++ ICE(segmentation fault) when compiling a huge static array of sufficiently complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
--- Comment #6 from Richard Biener ---
So with a debug build I can see
(gdb) run
Starting program: /home/abuild/rguenther/gcc8-g/gcc/cc1plus -quiet
/tmp/CodePoint.ii
Program received signal SIGSEGV, Segmentation fault.
0x01576cf6 in verify_vssa (bb=,
current_vdef=, visited=0x1389be00)
at /space/rguenther/src/svn/gcc-8-branch/gcc/tree-ssa.c:632
632 if (bitmap_bit_p (visited, bb->index))
(gdb) p bb
$1 =
(ick btw, that are many basic blocks)
and the SEGFAULT is a stack overflow due to recursion in verify_vssa which
does
/* Verify destination PHI uses and recurse. */
edge_iterator ei;
edge e;
FOR_EACH_EDGE (e, ei, bb->succs)
{
gphi *phi = get_virtual_phi (e->dest);
if (phi
&& PHI_ARG_DEF_FROM_EDGE (phi, e) != current_vdef)
{
error ("PHI node with wrong VUSE on edge from BB %d",
e->src->index);
print_gimple_stmt (stderr, phi, 0, TDF_VOPS);
fprintf (stderr, "expected ");
print_generic_expr (stderr, current_vdef);
fprintf (stderr, "\n");
err = true;
}
/* Recurse. */
err |= verify_vssa (e->dest, current_vdef, visited);
which is of course stupid. I'll fix that.
Re-running with -fno-checking now to side-step the above issue (as said,
this is a --enable-checking build).
I do know we have some algorithms that recurse to dominator sons and
very likely the CFG structure will result in big recursion depth there
as well.
So maybe a workaround for you is to do ulimit -s unlimited?
[Bug middle-end/86437] runtime segfault on Fortran code with large array and -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86437 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > (In reply to Dominique d'Humieres from comment #1) > > WORKSFORME. AFAIR -Ofast implies -fstack-arrays. > > Yeah, right, -fstack-arrays is the crucial flag here. Shouldn't -fmax-stack-var-size be a useful workaround then? Unfortunately neither of those seems to help: -fmax-stack-var-size=8192 -fmax-stack-var-size=4096 -fmax-stack-var-size=2048
[Bug middle-end/86437] runtime segfault on Fortran code with large array and -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86437 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > WORKSFORME. AFAIR -Ofast implies -fstack-arrays. Yeah, right, -fstack-arrays is the crucial flag here. > What is the output of > > ulimit -s > > (kbytes, -s) 65532 for me? 8192 So, yes, I'm hitting the stack size. However, what is a bit strange is that I get this problem only when putting the ALLOCATE statement into a subroutine, which returns the allocated array, but not when allocating directly in the main program. Is this intended behavior? The documentation says: "-fstack-arrays Adding this option will make the Fortran compiler put all arrays of unknown size and array temporaries onto stack memory. If your program uses very large local arrays it is possible that you will have to extend your runtime limits for stack memory on some operating systems." This mentions 'local arrays', and I was also assuming that only local arrays will be put on the stack. In my example, Y1 and Y2 are not local, but declared in the main program. Only the allocation happens in a subroutine, but the arrays are returned to the main program via a subroutine argument ...
[Bug middle-end/86437] runtime segfault on Fortran code with large array and -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86437 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME. AFAIR -Ofast implies -fstack-arrays. What is the output of ulimit -s (kbytes, -s) 65532 for me?
[Bug target/86425] Spec 2006 soplex seems to be slower on PowerPC using -ffast-math than without -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86425 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #1 from Martin Jambor --- On AMD Zen CPUs at least, we found that the number of iterations executed by the hottest loop is considerably higher with -ffast-math (just patch the benchmark and see for yourself). The reason is that the benchmark iterates until some error is smaller than a given threshold and with -ffast-math we simply get there after more computation.
[Bug fortran/86416] [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416 --- Comment #3 from Dominique d'Humieres --- > Note, OpenMP 4.5 fortran support is incomplete, it is partially 4.0, > partially 4.5. Only C/C++ are complete. Does this apply also to pr86421? Would it be possible to have an error "not yet implemented" instead of an ICE?
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 Dominique d'Humieres changed: What|Removed |Added CC||gs...@t-online.de --- Comment #17 from Dominique d'Humieres --- *** Bug 86220 has been marked as a duplicate of this bug. ***
[Bug middle-end/86437] New: runtime segfault on Fortran code with large array and -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86437 Bug ID: 86437 Summary: runtime segfault on Fortran code with large array and -Ofast Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Reduced test case: program ACT implicit none integer, parameter :: N = 53, M = 2 integer :: i integer, dimension(1:2*N) :: list real(8), dimension(:,:), allocatable :: Y1, Y2 do i=1,2*N list(i) = min(i, N) end do call DoAllocate(Y1, 1,N, 1,M) call DoAllocate(Y2, 1,2*N, 1,2*M) call ArrayCopy(Y2(list(1:N),1:M), Y1) contains subroutine DoAllocate(a, l1, u1, l2, u2) real(8), allocatable, intent(inout) :: a(:,:) integer, intent(in):: l1, u1, l2, u2 allocate(a(l1:u1,l2:u2), source=0.0_8) end subroutine subroutine ArrayCopy(arrFrom, arrTo) real(8), dimension(:,:), intent(in):: arrFrom real(8), dimension(:,:), intent(inout) :: arrTo arrTo(:,:) = arrFrom(:,:) end subroutine end When compiling this with any recent gfortran version (4.7.x up to 9-trunk) using -Ofast, I get a segfault at runtime. Things that make the segfault disappear: * using gfortran 4.6.4 * using smaller M (e.g. M=2000) * using -O1, -O2 or -O3 (with these I can even make M much larger, e.g. M=20) Since the optimization level changes the behavior crucially, I assume this is more of a middle-end than a front-end issue.
[Bug fortran/86220] [9 Regression] ICE in gfc_conv_structure, at fortran/trans-expr.c:7789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86220 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres --- I think this is a duplicate of pr49278: mixing initialization with data is invalid. Replacing real :: a = 1 with real :: a allows the test to compile and give the right result. *** This bug has been marked as a duplicate of bug 49278 ***
[Bug driver/86357] -falign-{functions,loops,jumps} incorrectly reported as disabled by -Q --help=optimizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86357 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed in r262513.
[Bug c++/86429] [8/9 Regression] lambda capture breaks constexpr-ness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86429 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.2
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 --- Comment #6 from Martin Liška --- Started with r231671.
[Bug fortran/86416] [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416 --- Comment #2 from Jakub Jelinek --- Note, OpenMP 4.5 fortran support is incomplete, it is partially 4.0, partially 4.5. Only C/C++ are complete.
[Bug tree-optimization/86401] The "For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,..." opts are only in fold-const.c and in RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86401 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug debug/86413] [9 regression] gcc.dg/guality/pr48437.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86413 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug debug/86413] [9 regression] gcc.dg/guality/pr48437.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86413 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Jul 9 07:25:14 2018 New Revision: 262511 URL: https://gcc.gnu.org/viewcvs?rev=262511=gcc=rev Log: 2018-07-09 Richard Biener PR debug/86413 * dwarf2out.c (gen_block_die): For an early generated DIE always output high/low PC attributes. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug fortran/83192] ICE for printing derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83192 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dominique d'Humieres --- > Using GNU Fortran (GCC) 8.0.1 20180408 (experimental) from equation.com > the code now compiles, so there may have been a bug in their previous build. > I suggest closing this report. Closing as INVALID.
