[Bug c++/67918] New: -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67918 Bug ID: 67918 Summary: -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved) Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: 11throwaway11 at outlook dot com Target Milestone: --- Created attachment 36473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36473=edit preprocessed file Let me preface this bug report by saying that the following code compiles just fine on clang with -O3, on MSVC with their maximum optimizations and on g++ with -O1. And notice what weird steps (mentioned below) make the gcc build a binary that works well. I'll try to make this report as useful as I can, but keep in mind that I'm kinda rookie with compiling/debugging on Linux. I've removed as much code from my project as possible to still be able reproduce the bug. Then I noticed something strange: removing declarations of functions that are not even called anywhere (but they were used in my original project) fixes the problem, so I made a file called fix1.cpp w/o these functions. After using valgrind with my original project, I remember it pointed to the destructors of CryptoPP::*::(En-/De-)cryption objects. So I thought, what if I allocate those dynamically instead of statically and do not use 'delete' (=> never call the destructors), it worked. Then I added delete operators, and it still worked. Weird. So I made a file called fix2.cpp containing this approach. (but in this minimal testcase valgrind points to the destructor of the basic_string, although dynamically allocating CryptoPP's objects and still statically allocating std::string does the job, thus STL has NOTHING to do with it). Then I learned about -fsanitize=undefined, tried it: "execution reached __builtin_unreachable() call", tried to search what exactly could cause this, didn't find anything remotely useful. So I thought, since clang compiles it just fine, what if I use their -fsanitize=undefined, got: "null pointer passed as argument" and it pointed to a /cryptopp/misc.h, line #149. They were calling memcpy without nullptr check. Alright, fine, thought I. Added such a check. Recompiled with clang, fsanitize was silent this time. So it's time to recompile with gcc, thought I. No, still crashes. Still the same "__builtin_unreachable()". But it's silent for binaries created from fix1.cpp and fix2.cpp. -Wall -Wextra shows no warnings. -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations makes no difference. Although I checked what's the difference between -O1 and -O2 and narrowed it down to -fdevirtualize. -O1 -fdevirtualize makes testcase.cpp create a corrupted binary. And it makes the same thing with fix1.cpp, but it worked fine with -O2. Alright, -O1 -fdevirtualize -fdevirtualize-speculatively makes fix1.cpp create a correct binary. Here's what I use to compile: g++ --std=c++11 -O3 -g -Wall -Wextra -save-temps -lcryptopp -lpthread Seems I can't attach more than 1 file (I'll try to add remaining .ii files in the comments though), so here's the link to a dropbox folder with everything (temp files, binaries compiled with -g, sources, makefile, gdb/valgrind/fsanitize outputs): https://www.dropbox.com/sh/0vr8i0mwuf2guk4/AADgQDd3S24v2Z7JzNejD71ja?dl=0 Below are the outputs of gcc -v, gdb bt and valgrind. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.2.0 (GCC) (gdb) file testcase Reading symbols from testcase...done. (gdb) run Starting program: /home/nick/Documents/CryptoPP/TESTCASE/testcase [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _Unwind_Resume (exc=exc@entry=0x0) at /build/gcc/src/gcc-5.2.0/libgcc/unwind.inc:229 229 /build/gcc/src/gcc-5.2.0/libgcc/unwind.inc: No such file or directory. (gdb) bt #0 _Unwind_Resume (exc=exc@entry=0x0) at
[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67918 --- Comment #2 from Nameless <11throwaway11 at outlook dot com> --- Created attachment 36475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36475=edit preprocessed file for fix2.cpp
[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67918 --- Comment #1 from Nameless <11throwaway11 at outlook dot com> --- Created attachment 36474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36474=edit preprocessed file for fix1.cpp
[Bug rtl-optimization/67814] cmp instruction register allocation error (x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67814
--- Comment #2 from Jameson ---
I did some further analysis with -dump-rtl-all -dump-tree-all. The SSA form
looked fine, as did the initial conversion to RTL. It seemed like something
confused the rtl-reload pass such that decided to reordered the statements:
size_t alsz = f(sz);
if (alsz > sz) { };
sz = alsz;
into:
size_t alsz = f(sz, al);
sz = alsz;
if (sz > sz) { };
I tried disabling that pass (--disable-rtl-reload), but it ran into a gcc
internal compiler error: in regstat_init_n_sets_and_refs, at regstat.c:67, so I
guess this pass is required by some later pass.
[Bug ada/32164] [4.9/5/6 Regression] ICE when renaming predefined "=" and "/="
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164 Alexandre Oliva changed: What|Removed |Added Status|NEW |RESOLVED CC||aoliva at gcc dot gnu.org Resolution|--- |FIXED --- Comment #21 from Alexandre Oliva --- This is fixed in all active branches.
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #12 from Martin Sebor --- Confirmed. As noted in bug 67911, the solution proposed for the next version of C++ is the following: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0035r0.html Until it's accepted and implemented, issuing a warning would help users avoid the trap. I happen to be working in this area so I'll see if I can come up with something.
[Bug rtl-optimization/67920] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #2 from Andrew Pinski --- Can you also compile with -fsanitize=undefined and try that? Can you also try -fsanitize=address ? This might detect if it is a bug in the code vs a bug in GCC.
[Bug c++/67919] GCC Compiler failed with "gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67919 Xinus changed: What|Removed |Added CC||spsarolkar at gmail dot com --- Comment #1 from Xinus --- Created attachment 36476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36476=edit preprocessed source Attached is the processor source
[Bug fortran/65223] Elemental type-bound procedure's passed object with INTENT(OUT) should be accepted with -std=f2003 (?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65223
--- Comment #5 from Dominique d'Humieres ---
The patch
--- ../_clean/gcc/fortran/resolve.c 2015-10-07 02:32:16.0 +0200
+++ gcc/fortran/resolve.c 2015-10-10 17:01:17.0 +0200
@@ -415,7 +415,7 @@ resolve_formal_arglist (gfc_symbol *proc
}
/* F08:C1278a. */
- if (sym->ts.type == BT_CLASS && sym->attr.intent == INTENT_OUT)
+ if ( !gfc_notification_std (GFC_STD_F2008) && sym->ts.type ==
BT_CLASS && sym->attr.intent == INTENT_OUT)
{
gfc_error ("INTENT(OUT) argument %qs of pure procedure %qs at %L"
" may not be polymorphic", sym->name, proc->name,
allows the code to compile with -std=f2003.
[Bug rtl-optimization/67920] New: wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 Bug ID: 67920 Summary: wrong code with -O3 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com Target Milestone: --- Some change to trunk made in the last 18 days is making gcc miscompile the files libavcodec/jpeg2000dec.c libavcodec/j2kenc.c and libavcodec/avuidec.c from ffmpeg git head when -O3 is used. This doesn't happen with -O2. I tested with x86_64-pc-linux-gnu only. How to reproduce: git clone git://git.videolan.org/ffmpeg.git && cd ffmpeg && ./configure make fate-vsynth1-jpeg2000 fate-vsynth1-avui The tests will fail, the former showing both the encoder and decoder are producing garbage, and the latter only the decoder. Adding -fno-strict-aliasing -fwrapv does not make a difference. The command Makefile uses to compile all three files looks like this: gcc -I. -I/home/jamrial/ffmpeg/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -DHAVE_AV_CONFIG_H -std=c99 -fomit-frame-pointer -pthread -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -c -o OUTPUT.o INPUT.c You can get that kind of verbose output by running make with V=1. Keep in mind you'll probably run into pr67794 while bisecting gcc trunk to find the commit that introduced this regression. Apologizes for not having a simpler test case.
[Bug fortran/65223] Elemental type-bound procedure's passed object with INTENT(OUT) should be accepted with -std=f2003 (?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65223 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW Summary|Regresion on elemental |Elemental type-bound |type-bound procedure's |procedure's passed object |passed object with |with INTENT(OUT) should be |INTENT(OUT) |accepted with -std=f2003 ||(?). --- Comment #4 from Dominique d'Humieres --- AFAICT the condition if (sym->ts.type == BT_CLASS && sym->attr.intent == INTENT_OUT) implement the constraints C1290 (from my copy of the f2015 draft, see fortran.dg/class_dummy_5.f90 for the rationale) 1.6.4 Fortran 2003 compatibility ... 6 Fortran 2003 permitted the function result of a pure function to be a polymorphic allocatable variable, and to be finalizable by an impure final subroutine. These are not permitted by this part of ISO/IEC 1539. 7 Fortran 2003 permitted an INTENT (OUT) argument of a pure subroutine to be polymorphic; that is not permitted by this part of ISO/IEC 1539. 12.7 Pure procedures ... C1289 An INTENT (OUT) dummy argument of a pure procedure shall not be such that finalization of the actual argument would reference an impure procedure. C1290 An INTENT (OUT) dummy argument of a pure procedure shall not be polymorphic. Since the constraints are Fortran 2008, IMO the code should compile with -std=f2003. In addition I am not sure that constraint C1289 is implemented: compiling module storage_mod implicit none private save type, public :: StorageClass character(20) :: name = 'default' contains procedure, nopass :: destroy => destroyStorage end type contains elemental subroutine destroyStorage(this) type(StorageClass), intent(OUT) :: this end subroutine end module storage_mod end should give an error(?).
[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67918 Nameless <11throwaway11 at outlook dot com> changed: What|Removed |Added Attachment #36475|0 |1 is obsolete|| --- Comment #3 from Nameless <11throwaway11 at outlook dot com> --- Created attachment 36477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36477=edit preprocessed file for fix2.cpp Sorry, I uploaded an outdated fix2 (missing delete operators), reuploaded it now. Also uploaded diffs between .cpps into the dropbox folder mentioned in the original bug report.
[Bug rtl-optimization/67920] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #1 from James Almer --- For reference you can also check http://fate.ffmpeg.org/report.cgi?time=20151010052205=x86_64-archlinux-gcc-experimental
[Bug c++/67919] New: GCC Compiler failed with "gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67919 Bug ID: 67919 Summary: GCC Compiler failed with "gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand" Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: spsarolkar at gmail dot com Target Milestone: --- I am trying to build my own lfs system for Raspberry PI 2. As a part of it I am trying to compile gcc on Raspberry PI 2, with raspbian as a base operating system. I could build the binutils using the instructions on lfs development version. But while compiling gcc I am getting below error g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.2.0/gcc -I../../gcc-5.2.0/gcc/. -I../../gcc-5.2.0/gcc/../include -I../../gcc-5.2.0/gcc/../libcpp/include -I/mnt/lfs/sources/gcc-build/./gmp -I/mnt/lfs/sources/gcc-5.2.0/gmp -I/mnt/lfs/sources/gcc-build/./mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpc/src -I../../gcc-5.2.0/gcc/../libdecnumber -I../../gcc-5.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.2.0/gcc/../libbacktrace -o except.o -MT except.o -MMD -MP -MF ./.deps/except.TPo ../../gcc-5.2.0/gcc/except.c g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.2.0/gcc -I../../gcc-5.2.0/gcc/. -I../../gcc-5.2.0/gcc/../include -I../../gcc-5.2.0/gcc/../libcpp/include -I/mnt/lfs/sources/gcc-build/./gmp -I/mnt/lfs/sources/gcc-5.2.0/gmp -I/mnt/lfs/sources/gcc-build/./mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpc/src -I../../gcc-5.2.0/gcc/../libdecnumber -I../../gcc-5.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.2.0/gcc/../libbacktrace -o explow.o -MT explow.o -MMD -MP -MF ./.deps/explow.TPo ../../gcc-5.2.0/gcc/explow.c g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.2.0/gcc -I../../gcc-5.2.0/gcc/. -I../../gcc-5.2.0/gcc/../include -I../../gcc-5.2.0/gcc/../libcpp/include -I/mnt/lfs/sources/gcc-build/./gmp -I/mnt/lfs/sources/gcc-5.2.0/gmp -I/mnt/lfs/sources/gcc-build/./mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpc/src -I../../gcc-5.2.0/gcc/../libdecnumber -I../../gcc-5.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.2.0/gcc/../libbacktrace -o expmed.o -MT expmed.o -MMD -MP -MF ./.deps/expmed.TPo ../../gcc-5.2.0/gcc/expmed.c ../../gcc-5.2.0/gcc/wide-int.h: In function 'long long unsigned int choose_multiplier(long long unsigned int, int, int, long long unsigned int*, int*, int*)': ../../gcc-5.2.0/gcc/wide-int.h:798:57: warning: array subscript is below array bounds [-Warray-bounds] ../../gcc-5.2.0/gcc/wide-int.h:798:57: warning: array subscript is below array bounds [-Warray-bounds] g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.2.0/gcc -I../../gcc-5.2.0/gcc/. -I../../gcc-5.2.0/gcc/../include -I../../gcc-5.2.0/gcc/../libcpp/include -I/mnt/lfs/sources/gcc-build/./gmp -I/mnt/lfs/sources/gcc-5.2.0/gmp -I/mnt/lfs/sources/gcc-build/./mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpfr/src -I/mnt/lfs/sources/gcc-5.2.0/mpc/src -I../../gcc-5.2.0/gcc/../libdecnumber -I../../gcc-5.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.2.0/gcc/../libbacktrace -o expr.o -MT expr.o -MMD -MP -MF ./.deps/expr.TPo ../../gcc-5.2.0/gcc/expr.c ../../gcc-5.2.0/gcc/expr.c: In function 'void store_constructor(tree, rtx, int, long long int)': ../../gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand Please submit a full bug report,
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #11 from Martin Sebor --- *** Bug 67911 has been marked as a duplicate of this bug. ***
[Bug c++/67911] new expression fails to align overaligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67911 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Sebor --- (In reply to Marc Glisse from comment #1) > (I thought we already had a PR or 2 about this) > The future is likely to be based on > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0035r0.html > but sadly this is moving forward quite slowly. > > Users can override the global operator new, so we have no way (unless > -fwhole-program or -flto) to know if this alignment is handled or not. This > of course does not prevent from having a warning that people can chose to > enable/disable. Thanks for the link. You're right, there already are a few bugs in Bugzilla about this. They're all marked as duplicates of bug 36159 (the subject of that bug is a little misleading, but the test case is clear enough). *** This bug has been marked as a duplicate of bug 36159 ***
[Bug rtl-optimization/67920] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #3 from James Almer --- (In reply to Andrew Pinski from comment #2) > Can you also compile with -fsanitize=undefined and try that? Can you also > try -fsanitize=address ? > > This might detect if it is a bug in the code vs a bug in GCC. Can't check with gcc 6 because of pr67921, but asan/ubsan in gcc 5.2.0 and clang 3.1 apparently don't complain about the code. ubsan gcc 5.2.0: http://fate.ffmpeg.org/report.cgi?time=20151010033356=x86_64-archlinux-gcc-ubsan asan gcc 5.2.0: http://fate.ffmpeg.org/report.cgi?time=20151010181435=x86_64-archlinux-gcc-asan Clang 3.1 asan: http://fate.ffmpeg.org/report.cgi?time=20151010171909=x86_64-debian-asan-144800
[Bug libstdc++/67922] New: std::unordered_map::clear should take time linear in the number of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67922
Bug ID: 67922
Summary: std::unordered_map::clear should take time linear in
the number of elements
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: yegor.derevenets at gmail dot com
Target Milestone: ---
std::unordered_map::clear internally clears the whole array of buckets using
memset. Consequently, the clearing time is proportional to the number of
buckets, instead of being proportional to the number of elements, which one
would expect, and what arguably should be the case according to the C++
Standard. (The Standard specifies that clear's complexity is linear, but
unfortunately does not say, linear in what.) This leads to terrible performance
of the following code:
#include
int main() {
std::unordered_map m;
for (int i = 0; i < 100; ++i) {
m[i] = i;
}
for (int i = 0; i < 1000; ++i) {
m.clear();
}
}
$ g++-5 -O2 test.cpp -std=c++11 && time ./a.out
real0m4.009s
user0m3.924s
sys 0m0.028s
$ clang++-3.7 -stdlib=libstdc++ -O2 test.cpp -std=c++11 && time ./a.out
real0m4.153s
user0m3.976s
sys 0m0.036s
If you build the same program with libc++, the problem goes away:
$ clang++-3.7 -stdlib=libc++ -O2 test.cpp -std=c++11 && time ./a.out
real0m0.165s
user0m0.128s
sys 0m0.036s
You can achieve similar performance with libstdc++ if you implement clear()
manually in the most naive way:
#include
int main() {
std::unordered_map m;
for (int i = 0; i < 100; ++i) {
m[i] = i;
}
for (int i = 0; i < 1000; ++i) {
while (m.begin() != m.end()) {
m.erase(m.begin());
}
}
}
$ g++-5 -O2 test.cpp -std=c++11 && time ./a.out
real0m0.167s
user0m0.132s
sys 0m0.028s
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-21'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151003 (Debian 5.2.1-21)
[Bug c++/67918] -fdevirtualize causes binary to crash with Segmentation Fault (CryptoPP involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67918
--- Comment #4 from Nameless <11throwaway11 at outlook dot com> ---
A little update.
I decided to check the piece of code that was causing "execution reached
__builtin_unreachable() call". So here's it:
virtual void ResizeBuffers()
{
m_register.New(m_cipher->BlockSize());
}
Here's the BlockSize:
inline unsigned int BlockSize() const {assert(m_register.size() > 0); return
(unsigned int)m_register.size();}
I thought: probably __builtin_unreachable() is what happens when the assert
gets called with 'false'.
So I changed ResizeBuffers() to:
virtual void ResizeBuffers()
{
printf("m_register: %p\nm_cipher: %p\n", _register, m_cipher); //
m_cipher is a pointer
m_register.New(m_cipher->BlockSize());
}
To check whether it does something with a NULL pointer.
And now's the weird part: it made the code work.
If I comment out printf(), it breaks again.
I've no idea what's going on.
[Bug sanitizer/67921] New: "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921 Bug ID: 67921 Summary: "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jamrial at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 36478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36478=edit Preprocessed source as generated by -freport-bug /home/jamrial/ffmpeg/libavcodec/dcaenc.c: In function ‘calc_masking’: /home/jamrial/ffmpeg/libavcodec/dcaenc.c:497:13: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147 static void calc_masking(DCAEncContext *c, const int32_t *input) ^ 0x11b8044 build_polynomial_chrec /home/jamrial/gcc-svn/gcc/tree-chrec.h:147 0xb9d6b9 interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1820 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9d75d interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1866 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9d78e interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1805 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9d4ee interpret_rhs_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1795 0xb99d34 interpret_expr /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1896 0xb99d34 analyze_scalar_evolution_1 /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:1957 0xb9a837 analyze_scalar_evolution(loop*, tree_node*) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2046 0xb9e0ca analyze_scalar_evolution_in_loop /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:2142 0xb9e212 simple_iv(loop*, loop*, tree_node*, affine_iv*, bool) /home/jamrial/gcc-svn/gcc/tree-scalar-evolution.c:3252 0xc10bf8 find_givs_in_stmt_scev /home/jamrial/gcc-svn/gcc/tree-ssa-loop-ivopts.c:1220
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #5 from Dominique d'Humieres --- Apparently there is a nasty bug somewhere: if I sort 'String = 2 ' 'String = 9 ' 'String = 8 ' 'String = 7 ' 'String = 6 ' 'String = 5 ' 'String = 4 ' 'String = 3 ' 'String = 10 ' 'String = 1 ' I get String = 2 String = 1 String = 10 String = 3 String = 4 String = 5 String = 6 String = 7 String = 8 String = 9
[Bug fortran/67805] ICE on array constructor with wrong character specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67805 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0 --- Comment #3 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/67744] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I get the compile-time error with 4.8 up to trunk (6.0). Note that code compiles if I replace the line call g%write() with call write(g) and outputs "OK" at run time. I get the same result if I add a line call write(retfoo(op)) but call retfoo(op)%write() is rejected with the error pr67744_db.f90:40:17: call retfoo(op)%write() 1 Error: Syntax error in CALL statement at (1) I wonder if 'call g%write()' is valid.
[Bug fortran/43310] -pedantic errors involving PARAMETERs and out of range result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #16 from Dominique d'Humieres --- > What should be done with this two and a half year old PR? > Apply the patch in comment #14 or closing it as INVALID or WONTFIX? After more than two years without feedback closing as WONTFIX.
[Bug fortran/66495] [5 Regression] Issue with same name for embedded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66495 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominique d'Humieres --- > I doubt the r223614 will be back ported. This > should probably closed as fixed on trunk. If > no one objects I'll close this PR in a few days. No feedback, closing as FIXED.
[Bug fortran/66534] Compilation error of gfortran building on YDL6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66534 --- Comment #5 from Dominique d'Humieres --- > As the result the error above not generated but I see the next bug (See > below). > I am guessing many errors embedded for YDL 6.2, since > my hardware (Old iBook; Power PC G3 Processor) is very outdated, > probably nobody wishes to test it except me. Did you asked yellow dog linux for help? > One option is that not to fix further bugs for Power PC G3 Processor > to save developer's time. This option is OK for me because using > gfortran on my outdated hardware is not significant. > Another option is to continue bug fixing to improve gfortran sources. > Let me know which one is preferable for gfortran developers? Well, gfortran is built on a quite broad range of platforms without the problem you report. Unless you tackle the issue yourself, the problem will not be fixed before the death of your G3! IMO it would be more honest to close this PR as WONTFIX.
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968 --- Comment #2 from Dominique d'Humieres --- Is the problem fixed? Without feedback I'll assume yes.
[Bug fortran/51292] RESULT var with -finit-local-zero -fno-automatic results in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- > Could this PR be closed as fixed? No feedback for over a year and a half. Closing as FIXED.
[Bug fortran/57530] [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > The codes in comments 0 and 2 compile with gfortran 4.9.1 and trunk (5.0). > Should not this PR resolved as FIXED and a new PR open for the remaining > issue in comment 8? No feedback for over a year. Closing as FIXED. Please open new PR(s) with a test case if there are remaining issue(s).
[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 Bug 63205 depends on bug 57530, which changed state. Bug 57530 Summary: [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/40881] [F03] warn for obsolescent features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominique d'Humieres --- > IMO it does not make sense to warn for fixed form. Any objection to close > this PR as FIXED? No feedback, closing as FIXED.
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 40881, which changed state. Bug 40881 Summary: [F03] warn for obsolescent features https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/32817] MODULE functions are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817 Bug 32817 depends on bug 25708, which changed state. Bug 25708 Summary: [F95] Module loading is not good at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/25391] Module derived type issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25391 Bug 25391 depends on bug 25708, which changed state. Bug 25708 Summary: [F95] Module loading is not good at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130 Bug 21130 depends on bug 25708, which changed state. Bug 25708 Summary: [F95] Module loading is not good at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/25708] [F95] Module loading is not good at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #25 from Dominique d'Humieres --- > I wonder if this PR has not been fixed by recent changes. No feedback, Closing as FIXED.
[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285 Bug 30285 depends on bug 25708, which changed state. Bug 25708 Summary: [F95] Module loading is not good at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/31139] sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dominique d'Humieres --- > The change occured between 4.5 and 4.6 (note that 4.6 and 4.7 gives > 0.263675928 without -funroll-loops). Is this still an issue? No feedback for over two years. Closing as FIXED.
[Bug middle-end/67912] [6 regression] ICE in gen_lowpart_common, at emit-rtl.c:1399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67912 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I think this bug affects all platforms, see the thread https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01013.html.
[Bug fortran/53357] Add -fcheck=bounds for character type-spec in ALLOCATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53357 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Dominique d'Humieres --- Still present at r228660.
[Bug fortran/47876] Host-assoc generic subroutine plus intrinsic function not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47876 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still no error at r228660.
[Bug c++/67917] New: ICE in openssl-1.0.2d.tar.gz "/usr/include/openssl/bn.h:335:3: error: TYPE_CANONICAL is not compatible"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67917
Bug ID: 67917
Summary: ICE in openssl-1.0.2d.tar.gz
"/usr/include/openssl/bn.h:335:3: error:
TYPE_CANONICAL is not compatible"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../configure --enable-languages=c,c++
Thread model: posix
gcc version 6.0.0 20151004 (experimental) (GCC)
---
/usr/include/openssl/bn.h:335:3: error: TYPE_CANONICAL is not compatible
{
^
asm_written public unsigned type_6 DI
size
unit size
align 64 symtab 171348768 alias set -1 canonical type 0x143c272a0
pointer_to_this reference_to_this
>
decl_3 VOID file /usr/include/openssl/bn.h line 333 col 8
align 1 offset_align 1 context
chain
decl_3 VOID file /usr/include/openssl/bn.h line 332 col 15
align 1 offset_align 1 context chain >> context
full-name "struct bn_gencb_st"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
full-name "BN_GENCB"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
/usr/include/openssl/bn.h:335:3: internal compiler error: verify_type failed
/usr/include/openssl/bn.h:335:3: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)
[Bug fortran/56423] F08/0071: Shall reject invalid Vector subscript target with Pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0 --- Comment #1 from Dominique d'Humieres --- >From my version of the F2015 draft C725 (R737) The expr shall be a designator that designates a variable with either the TARGET or POINTER attribute and is not an array section with a vector subscript, or it shall be a reference to a function that returns a data pointer. Note that 't(x( [ 1,4,9,25 ] ))' is not rejected but gives an ICE from 4.8 up to trunk (6.0): [Book15] f90/bug% gfortran pr56423.f90 pr56423.f90:11:0: y = t(x( [ 1,4,9,25 ] )) ! (4) ! Invalid per IR F08/0071 but not rejected 1 internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6702 where gfortran is 5.2.0.
[Bug middle-end/67714] [6 Regression] signed char is zero-extended instead of sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67714 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan --- Confirmed.
[Bug fortran/56156] Reject calls to external procedures using non-module declared TYPEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56156 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- The code compiles without error at r228660.
[Bug tree-optimization/60919] [arm] gcc fails to tail call __builtin_ffsll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60919 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 CC||ramana at gcc dot gnu.org Component|target |tree-optimization Ever confirmed|0 |1 Severity|minor |enhancement --- Comment #1 from Ramana Radhakrishnan --- Confirmed.
[Bug driver/60358] [patch] ARM support broken for Haiku
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2015-10-10 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan --- No activity on this report for quite a while . Patches need to be on gcc-patc...@gcc.gnu.org please.
[Bug fortran/64097] Bug with nested WHERE constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64097 --- Comment #2 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #1) > WORKSFORME on x86_64-apple-darwin14 with 4.8 up to trunk (6.0) and the > various options I tried: > > [Book15] f90/bug% gfortran pr64097.f90 -fcheck=all -fsanitize=address > [Book15] f90/bug% a.out >0 > 58 > > gfortran is 5.2. I think the trapping of exceptions must be enabled. % gfortran --version GNU Fortran (GCC) 5.1.0 % gfortran -O -march=native -g -ffpe-trap=zero,overflow,invalid nested-where.f90 && ./a.out 0 Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7F09C1E59B97 #1 0x7F09C1E58D90 #2 0x7F09C1430F4F #3 0x7F09C1BE7277 #4 0x7F09C1BEBE50 #5 0x400A34 in MAIN__ at nested-where.f90:0 Floating exception Without -ffpe-trap=... I get the same as you.
[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #37 from Alexandre Oliva --- Author: aoliva Date: Sat Oct 10 12:05:56 2015 New Revision: 228674 URL: https://gcc.gnu.org/viewcvs?rev=228674=gcc=rev Log: Reset inlined debug variables at the end of the inlined function for gcc/ChangeLog PR debug/58315 * tree-inline.c (reset_debug_binding): New. (reset_debug_bindings): Likewise. (expand_call_inline): Call it. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/tree-inline.c
[Bug fortran/64097] Bug with nested WHERE constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64097 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0 --- Comment #3 from Dominique d'Humieres --- > I think the trapping of exceptions must be enabled. Confirmed.
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 41107, which changed state. Bug 41107 Summary: [F03] Proc-pointer components: Fix calling DECL for f2c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41107 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug fortran/56203] gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Dominique d'Humieres --- No feedback, closing as WONTFIX.
[Bug fortran/41107] [F03] Proc-pointer components: Fix calling DECL for f2c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41107 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dominique d'Humieres --- No feedback. Closing as INVALID. If you have a pertinent test case, please open a new PR with the required information.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed with 5.2 and 6.0. I get the following ICE with 4.9 pr67740.f90:20:0: internal compiler error: in gimplify_expr, at gimplify.c:8538 allocate(character(4) :: myBase%string) the change occurred between revisions r221423 (2015-03-13, ICE) and r2214164+patches (2015-03-16, compiles).
[Bug fortran/64097] Bug with nested WHERE constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64097 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME on x86_64-apple-darwin14 with 4.8 up to trunk (6.0) and the various options I tried: [Book15] f90/bug% gfortran pr64097.f90 -fcheck=all -fsanitize=address [Book15] f90/bug% a.out 0 58 gfortran is 5.2.
[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-10-10 CC||ramana at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |chrbr at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan --- Confirmed.
[Bug rtl-optimization/67715] [6 Regression][ARM] ICE in cselib.c during reload_cse_regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67715 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- Confirmed.
[Bug target/63346] xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63346 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-10 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- Please try and provide a testcase to figure out what the problem might be. Without this it is very hard to work out what is going on in this particular case.
[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #36 from Alexandre Oliva --- Created attachment 36472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36472=edit backported patch for the 4.9 branch Chris, retbnd is of no concern, nothing equivalent existed back then. call_stmt was called gimple_call. Here's a backported patch, barely tested. Please let me know how it goes for you.
[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #38 from Alexandre Oliva --- I've finally installed the patch in the gcc-5-branch too.
[Bug fortran/49138] Add /usr/include/fortran/{,gcc-} to the file/module search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres --- Let me mark this PR as duplicate of pr35707 (no need to have two inactive PRs opened). *** This bug has been marked as a duplicate of bug 35707 ***
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
Bug 35707 depends on bug 49138, which changed state.
Bug 49138 Summary: Add /usr/include/fortran/{,gcc-} to the file/module
search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707 --- Comment #17 from Dominique d'Humieres --- *** Bug 49138 has been marked as a duplicate of this bug. ***
[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522 Dominique d'Humieres changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #10 from Dominique d'Humieres --- Compiling various variants of the test with 4.8 up to trunk (6.0) under valgrind does not give valgrind error (while I get some with 4.5 and 4.6). Am I missing something?
[Bug fortran/43899] Wrong unused-variable warning with NAMELISTs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43899 Dominique d'Humieres changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Dominique d'Humieres --- > If there is a real need for a warning for unused namelist or namelist items, > then a new PR should be open and this one closed. IMO it is just a waste of > time: > unused stuff having a strong tendency to produce false positive. No feedback for more than two years. Closing as WONTFIX. Please open new PR(s) for remaining issue(s).
