[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #6 from David Kredba nheghathivhistha at gmail dot com --- Hello, Before reporting this to you I opened a Mesa bug where they suggested me to try released version of GCC. Gcc-4.8.2 works for them with -flto=4. This report is result of that suggestion. It works for me too with gcc-4.8.2. I had LTO commented out for mesa long time and not tested it again after gcc-4.8.2 was released. https://bugs.freedesktop.org/show_bug.cgi?id=72672 Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0-alpha20131208/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131208/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131208/work/gcc-4.9-20131208/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0-alpha20131208 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131208/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131208 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131208/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131208/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131208/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --disable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131208/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.0_alpha20131208' Thread model: posix gcc version 4.9.0-alpha20131208 20131208 (experimental) (Gentoo 4.9.0_alpha20131208) Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.2/work/gcc-4.8.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --disable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2 p1.0' Thread model: posix gcc version 4.8.2 (Gentoo 4.8.2 p1.0) Thank you.
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #7 from Markus Trippelsdorf octoploid at yandex dot com --- Gcc now uses slim-LTO-objects by default. Therefore you need to run binutils (ar, nm, ranlib) that use the linker plugin. You can use gcc-ar, etc. for this purpose.
[Bug fortran/59502] [OOP] ICE on invalid on pointer assignment to non-pointer CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59502
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-12-14
CC||janus at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
Summary|ICE on invalid on pointer |[OOP] ICE on invalid on
|assignment to non-pointer |pointer assignment to
|CLASS |non-pointer CLASS
Ever confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. Patch:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(revision 205960)
+++ gcc/fortran/primary.c(working copy)
@@ -2039,9 +2039,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
if (m != MATCH_YES)
return m;
}
- else if (component-ts.type == BT_CLASS
-CLASS_DATA (component)-as != NULL
-!component-attr.proc_pointer)
+ else if (component-ts.type == BT_CLASS component-attr.class_ok
+CLASS_DATA (component)-as !component-attr.proc_pointer)
{
tail = extend_ref (primary, tail);
tail-type = REF_ARRAY;
[Bug fortran/35040] usage of init expression in its own definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #8 from janus at gcc dot gnu.org --- Status: * both examples and comment 1 and some of comment 3 are being rejected since quite some time (4.4 at least) * comment 0 and part of comment 3 is still (wrongly) accepted * comment 4 is (correctly) accepted
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #11 from sonoro at telefonica dot net --- So it seems you solved the problem in sjlj Are you going to push it? Thanks victor
[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #6 from janus at gcc dot gnu.org --- Author: janus Date: Sat Dec 14 10:31:56 2013 New Revision: 205983 URL: http://gcc.gnu.org/viewcvs?rev=205983root=gccview=rev Log: 2013-12-14 Janus Weil ja...@gcc.gnu.org PR fortran/59450 * module.c (mio_expr): Handle type-bound function expressions. 2013-12-14 Janus Weil ja...@gcc.gnu.org PR fortran/59450 * gfortran.dg/typebound_proc_31.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_proc_31.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to bugs from comment #5) just wanted to say thanks. Your speed is terrific :) you're welcome :) The fix has landed on trunk by now. If the example you posted is part of a larger code base, it would be great if you could test the full code with a current gfortran trunk build. In case your code is publicly available, I can also test it for you.
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #8 from David Kredba nheghathivhistha at gmail dot com --- Thank you Markus. Could you please tell me if binutils 2.24.51.0.2 are OK for this? I will try AR=gcc-ar etc in the meantime.
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 --- Comment #5 from janus at gcc dot gnu.org --- Here is a simpler patch (which could even be considered for backporting to 4.8): Index: gcc/fortran/class.c === --- gcc/fortran/class.c(revision 205982) +++ gcc/fortran/class.c(working copy) @@ -2424,7 +2424,7 @@ gfc_find_intrinsic_vtab (gfc_typespec *ts) return NULL; /* Sometimes the typespec is passed from a single call. */ - if (ts-type == BT_DERIVED) + if (ts-type == BT_DERIVED || ts-type == BT_CLASS) return gfc_find_derived_vtab (ts-u.derived); /* Find the top-level namespace. */
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #9 from Markus Trippelsdorf octoploid at yandex dot com --- (In reply to David Kredba from comment #8) Thank you Markus. Could you please tell me if binutils 2.24.51.0.2 are OK for this? Unfortunately not out of the box. I use the attached simple patch for binutils. With this I can symlink to the linker plugin in /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins (my be a different directory on your machine) and ar, nm and ranlib will use the plugin by default. I can also switch between gcc and llvm plugins, e.g.: markus@x4 ~ % plugin_gcc markus@x4 ~ % ll /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins total 12K drwxr-xr-x 2 root root 4.0K Dec 14 12:01 . drwxr-xr-x 3 root root 4.0K Oct 7 2012 .. lrwxrwxrwx 1 root root 65 Dec 14 12:01 liblto_plugin.so.0.0.0 - /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/liblto_plugin.so.0.0.0 markus@x4 ~ % plugin_clang markus@x4 ~ % ll /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins total 8.0K drwxr-xr-x 2 root root 4.0K Dec 14 12:01 . drwxr-xr-x 3 root root 4.0K Oct 7 2012 .. lrwxrwxrwx 1 root root 26 Dec 14 12:01 LLVMgold.so - /usr/local/lib/LLVMgold.so markus@x4 ~ % Where plugin_gcc and plugin_clang are simple scripts to change the symlink. I will try AR=gcc-ar etc in the meantime. This should work.
[Bug libstdc++/50160] vectorbool comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 tysonroy tysonroy at yopmail dot fr changed: What|Removed |Added CC||tysonroy at yopmail dot fr --- Comment #38 from tysonroy tysonroy at yopmail dot fr --- It is a really useful post that helps to simplify the issues and also helps to clarify the doubts regarding vectors and bool. Awaiting new posts. a href=http://www.monsteribeatsbydrejp.com/;transparent music widget android/a
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #10 from Markus Trippelsdorf octoploid at yandex dot com --- Created attachment 31437 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31437action=edit binutils patch
[Bug go/59506] New: net FAILs (timeout) on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506 Bug ID: 59506 Summary: net FAILs (timeout) on alpha Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com $ gmake GOTESTFLAGS=--keep net/check panic: test timed out after 4m0s goroutine 112 [running]: testing.$nested6 ../../../gcc-svn/trunk/libgo/go/testing/testing.go:596 created by time.goFunc ../../../gcc-svn/trunk/libgo/go/time/sleep.go:123 goroutine 1 [chan receive]: testing.RunTests ../../../gcc-svn/trunk/libgo/go/testing/testing.go:472 testing.Main ../../../gcc-svn/trunk/libgo/go/testing/testing.go:403 main.main /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/_testmain.go:167 goroutine 110 [IO wait]: net.runtime_pollWait ../../../gcc-svn/trunk/libgo/runtime/netpoll.goc:121 net.Wait.pN12_net.pollDesc /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/fd_poll_runtime.go:81 net.WaitWrite.pN12_net.pollDesc /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/fd_poll_runtime.go:90 net.connect.pN9_net.netFD /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/fd_unix.go:86 net.dial.pN9_net.netFD /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/sock_posix.go:121 net.socket /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/sock_posix.go:91 net.internetSocket /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/ipsock_posix.go:136 net.dialTCP /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/tcpsock_posix.go:155 net.dialSingle /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial.go:225 net.$nested102 /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial.go:158 net.dial /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/fd_unix.go:40 net.Dial.pN10_net.Dialer /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial.go:165 net.Dial /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial.go:138 net.TestSelfConnect /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial_test.go:150 testing.tRunner ../../../gcc-svn/trunk/libgo/go/testing/testing.go:391 created by testing.RunTests ../../../gcc-svn/trunk/libgo/go/testing/testing.go:471 goroutine 13 [chan send]: net.$nested4 /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial_test.go:58 created by net.TestDialTimeout /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial_test.go:56 [... some 100 goroutines, all with the same backtrace ...] goroutine 109 [chan send]: net.$nested4 /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial_test.go:58 created by net.TestDialTimeout /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libgo/gotest13607/test/dial_test.go:56 Keeping gotest13607 FAIL: net Makefile:4567: recipe for target 'net/check' failed gmake: *** [net/check] Error 1
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #11 from David Kredba nheghathivhistha at gmail dot com --- Hello Markus, Thank you for your great support. AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib did it for me for mesa and I will use it in problematic future cases. And I will try your binutils patch. Do you think that for 4.9.0 GCC release binutils will support slim-LTO-objects? LTO support for general use in Gentoo will not be enabled without it in my opinion. (But maybe if USE/FEATURE lto will be detected they can let ebuild/emerge export AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib to environment.)
[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |rtl-optimization --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Recategorizing.
[Bug go/59506] net FAILs (timeout) on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 31438 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31438action=edit strace -f output Some ~30 seconds of strace dump.
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #12 from Markus Trippelsdorf octoploid at yandex dot com --- (In reply to David Kredba from comment #11) And I will try your binutils patch. Do you think that for 4.9.0 GCC release binutils will support slim-LTO-objects? LTO support for general use in Gentoo will not be enabled without it in my opinion. (But maybe if USE/FEATURE lto will be detected they can let ebuild/emerge export AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib to environment.) I'm not sure. I've posted the simple patch a while ago and it was ignored. BTW the best solution would be if one could install *both* plugins to the ../lib/bfd-plugins directory and the correct one would be used automatically. I don't know if anyone is working on that.
[Bug sanitizer/59503] Bogus integer-overflow error with long long with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59503 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sat Dec 14 12:19:56 2013 New Revision: 205984 URL: http://gcc.gnu.org/viewcvs?rev=205984root=gccview=rev Log: PR sanitizer/59503 * internal-fn.c (ubsan_expand_si_overflow_addsub_check): Call expand_binop with correct optab depending on code. testsuite/ * c-c++-common/ubsan/pr59503.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr59503.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/59503] Bogus integer-overflow error with long long with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59503 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug middle-end/59507] New: ICE: in mark_reachable_handlers, at tree-eh.c:3833 with -O -fnon-call-exceptions -fvtable-verify=preinit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59507 Bug ID: 59507 Summary: ICE: in mark_reachable_handlers, at tree-eh.c:3833 with -O -fnon-call-exceptions -fvtable-verify=preinit Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 31439 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31439action=edit reduced testcase Compiler output: $ gcc -O -fnon-call-exceptions -fvtable-verify=preinit testcase.C testcase.C: In function 'void print()': testcase.C:44:6: internal compiler error: in mark_reachable_handlers, at tree-eh.c:3833 void print () ^ 0xd1ca11 mark_reachable_handlers /mnt/svn/gcc-trunk/gcc/tree-eh.c:3833 0xd1cb52 remove_unreachable_handlers /mnt/svn/gcc-trunk/gcc/tree-eh.c:3866 0xd1e5f5 execute_cleanup_eh_1 /mnt/svn/gcc-trunk/gcc/tree-eh.c:4536 0xd1e5f5 execute_cleanup_eh /mnt/svn/gcc-trunk/gcc/tree-eh.c:4569 0xd1e5f5 execute /mnt/svn/gcc-trunk/gcc/tree-eh.c:4614 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-205916-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-205916-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.9.0 20131212 (experimental) (GCC)
[Bug middle-end/59507] ICE: in mark_reachable_handlers, at tree-eh.c:3833 with -O -fnon-call-exceptions -fvtable-verify=preinit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59507 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-14 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/59508] New: std::find could use specialized container's find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
Bug ID: 59508
Summary: std::find could use specialized container's find
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
It should be possible to invoke a container's specialized find function (e.g.
std::set::find, std::map::find, etc) from within std::find, if it is used in a
compatible way, i.e. std::find is invoked with begin and end iterators of the
container and a value ref.
This could be done by something like this ...
#include vector
#include set
#include type_traits
#include algorithm
namespace x
{
templateclass InputIt, class T, class Enable = void struct find_impl;
templateclass InputIt, class T
struct find_implInputIt, T, typename std::enable_ifstd::is_sametypename
std::setT::iterator, InputIt::value::type
{
static InputIt find (InputIt first, InputIt last, const T value)
{
// if first == container's begin () and
// last == container's end () can use optimized implementation of
// std::set::find.
// but to do that, must be able to get container ref from the given
// iterators somehow, or look at unique properties of begin () and end ()
// iterators as returned from the container.
return first;
}
};
templateclass InputIt, class T
struct find_implInputIt, T, typename std::enable_if!std::is_sametypename
std::setT::iterator, InputIt::value::type
{
static InputIt find (InputIt first, InputIt last, const T value)
{
return std::find (first, last, value);
}
};
templateclass InputIt, class T InputIt
find (InputIt first, InputIt last, const T value)
{
return find_implInputIt, T::find (first, last, value);
}
}
usage example:
int func1 (std::vectorint my_container)
{
return *x::find (my_container.begin (), my_container.end (), 5);
}
int func2 (std::setint my_container)
{
return *x::find (my_container.begin (), my_container.end (), 5);
}
If it's not possible to figure out whether an iterator is a container's begin
() or end () because it would require adding a data member to the iterator,
another option could be to return internal subclasses of std::set::iterator for
begin () and end () and then check the iterator types in std::find. However,
I'm not sure whether containers are allowed to do that according to the
standard.
[Bug ipa/59473] [4.9 Regression] ice in get_class_context with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59473 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-14 CC||mpolacek at gcc dot gnu.org Known to work||4.8.2 Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, -O3 is needed.
[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265 Markus Trippelsdorf octoploid at yandex dot com changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf octoploid at yandex dot com --- Created attachment 31440 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31440action=edit testcase with gcda Also happens during Firefox PGO build: markus@x4 src % c++ -w -c -fprofile-use -fprofile-correction -std=gnu++0x -O2 Unified_cpp_3.ii In file included from /var/tmp/moz-build-dir/js/src/Unified_cpp_3.cpp:137:0: /var/tmp/mozilla-central/js/src/jit/MCallOptimize.cpp: In member function ‘virtual void js::jit::LPhi::printInfo(FILE*)’: /var/tmp/mozilla-central/js/src/jit/MCallOptimize.cpp:1484:1: internal compiler error: Segmentation fault
[Bug fortran/59502] [OOP] ICE on invalid on pointer assignment to non-pointer CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59502 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) Patch: Regtests cleanly. Will commit as obvious.
[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Sat Dec 14 15:24:58 2013 New Revision: 205986 URL: http://gcc.gnu.org/viewcvs?rev=205986root=gccview=rev Log: * var-tracking.c (add_stores): Fix oversight in latest commit. Added: trunk/gcc/testsuite/gcc.dg/pr59350.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-*-* | Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Reopen if this still fails on x86-64.
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) Here is a simpler patch (which could even be considered for backporting to 4.8): Just verified that it is free of testsuite regressions.
[Bug other/59490] [4.9 Regression] cilk-plus failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59490
--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The following patch silences the failures:
--- ../_clean/gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc2013-12-11
19:35:38.0 +0100
+++ gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc2013-12-14
14:03:33.0 +0100
@@ -1,6 +1,6 @@
/* { dg-options -fcilkplus } */
/* { dg-do run { target i?86-*-* x86_64-*-* arm*-*-* } } */
-/* { dg-options -fcilkplus -lcilkrts { target { i?86-*-* x86_64-*-* arm*-*-*
} } } */
+/* { dg-options -mtune=generic -fcilkplus -lcilkrts { target { i?86-*-*
x86_64-*-* arm*-*-* } } } */
#include assert.h
#include unistd.h
However, while I understand that -mtune=* can change the content of dump files
as in pr59494 without any side effect on the generated code, I think the above
patch is only papering over a real bug.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT this is fixed by revision 205959: http://gcc.gnu.org/viewcvs/gcc?view=revisionsortby=daterevision=205959 Author:amker Date:Fri Dec 13 11:36:22 2013 UTC (28 hours, 17 minutes ago) Changed paths:8 Log Message: PR tree-optimization/58296 PR tree-optimization/41488 * tree-scalar-evolution.c: Include necessary header files. (simplify_peeled_chrec): New function. (analyze_evolution_in_loop): New static variable. Call simplify_peeled_chrec. * tree-ssa-loop-ivopts.c (mark_bivs): Don't mark peeled IV as biv. (add_old_iv_candidates): Don't add candidate for peeled IV. * tree-affine.h (aff_combination_zero_p): New function. PR tree-optimization/58296 PR tree-optimization/41488 * gcc.dg/tree-ssa/scev-7.c: New test. * gcc.dg/pr41488.c: New test. * g++.dg/pr59445.C: New test. Closing as FIXED.
[Bug target/59492] [4.9 Regression] multiarch function versioning fails to preserve -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 --- Comment #8 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Sat Dec 14 17:01:49 2013 New Revision: 205989 URL: http://gcc.gnu.org/viewcvs?rev=205989root=gccview=rev Log: Restore flag_pic in ix86_function_specific_restore gcc/ PR target/59492 * config/i386/i386.c (ix86_function_specific_restore): Don't change -fPIC. 2013-12-14 H.J. Lu hongjiu...@intel.com PR target/59492 * g++.dg/other/pr59492.C: New file. Added: trunk/gcc/testsuite/g++.dg/other/pr59492.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58857] [OOP] CLASS wrongly rejected in BLOCK DATA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58857 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-14 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org --- The whole idea of using CLASS(*) with BLOCK DATA is rather sick if you ask me ;) Anyway, here is a draft patch which helps to allow this bestiality (not regtested): Index: gcc/fortran/class.c === --- gcc/fortran/class.c(revision 205983) +++ gcc/fortran/class.c(working copy) @@ -644,7 +644,7 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a if (!gfc_add_component (fclass, _vptr, c)) return false; c-ts.type = BT_DERIVED; - if (delayed_vtab + if (delayed_vtab || ts-u.derived-attr.unlimited_polymorphic || (ts-u.derived-f2k_derived ts-u.derived-f2k_derived-finalizers)) c-ts.u.derived = NULL;
[Bug target/59492] [4.9 Regression] multiarch function versioning fails to preserve -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug fortran/59502] [OOP] ICE on invalid on pointer assignment to non-pointer CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59502 --- Comment #3 from janus at gcc dot gnu.org --- Author: janus Date: Sat Dec 14 17:47:22 2013 New Revision: 205990 URL: http://gcc.gnu.org/viewcvs?rev=205990root=gccview=rev Log: 2013-12-14 Janus Weil ja...@gcc.gnu.org PR fortran/59502 * primary.c (gfc_match_varspec): Check for 'class_ok'. 2013-12-14 Janus Weil ja...@gcc.gnu.org PR fortran/59502 * gfortran.dg/class_57.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_57.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59502] [OOP] ICE on invalid on pointer assignment to non-pointer CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59502 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from janus at gcc dot gnu.org --- Fixed with r205990. Closing. Thanks for the report!
[Bug c++/59509] New: template function definition. redefinition error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59509
Bug ID: 59509
Summary: template function definition. redefinition error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ich at az2000 dot de
Test case:
namespace X {
templatetypename T struct Mat{};
templatetypename T struct MatExpr {};
templatetypename T
MatExprT prod(MatT const A, MatT const B) { return MatExprT(); }
};
struct Mat2 {};
templatetypename T
X::MatT prod(X::MatT const A, Mat2 const B) { return X::MatT(); }
templatetypename T1, typename T2
auto operator*(const T1 a, const T2 b) - decltype(X::prod(a, b)) {
return X::prod(a, b);
}
templatetypename T1, typename T2
auto operator*(const T1 a, const T2 b) - decltype(prod(a, b)) {
return prod(a, b);
}
int main() {}
I get the error:
mathutils.hpp:77:6: error: redefinition of 'templateclass T1, class T2
decltype (prod(a, b)) operator*(const T1, const T2)'
auto operator*(const T1 a, const T2 b) - decltype(prod(a, b)) {
^
mathutils.hpp:72:6: note: 'templateclass T1, class T2 decltype
(viennacl::linalg::prod(a, b)) operator*(const T1, const T2)' previously
declared here
auto operator*(const T1 a, const T2 b) - decltype(viennacl::linalg::prod(a,
b)) {
^
It compiles fine with Clang 3.3.
[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) The fix has landed on trunk by now. ... therefore I'm closing this PR. Feel free to post any follow-up comments here, or open a new PR in case of further problems.
[Bug c++/59509] template function definition. redefinition error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59509
--- Comment #1 from Albert Zeyer ich at az2000 dot de ---
Sorry, that was the error from my real app. From the test case, the error is:
test_prodtempl.cpp:24:6: error: redefinition of 'templateclass T1, class T2
decltype (prod(a, b)) operator*(const T1, const T2)'
auto operator*(const T1 a, const T2 b) - decltype(prod(a, b)) {
^
test_prodtempl.cpp:19:6: note: 'templateclass T1, class T2 decltype
(X::prod(a, b)) operator*(const T1, const T2)' previously declared here
auto operator*(const T1 a, const T2 b) - decltype(X::prod(a, b)) {
^
[Bug fortran/52370] [4.7/4.8/4.9 Regression] Spurious may be used uninitialized warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-14 Summary|Spurious may be used |[4.7/4.8/4.9 Regression] |uninitialized warning for |Spurious may be used |check of optional argument |uninitialized warning for ||check of optional argument Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I get the warning with 4.6.4 up to trunk (r205944), but not for 4.5.4. The change occurred between revisions r182107 (2011-12-08) and r182980 (2012-01-07). That the warning only shows up in 4.7 but not in 4.7.2 is probably due to the patch for PR 50923. (The warning is only printed for -O1 but not for -O2 or -O0.) The fix for PR 50923 is in the above range.
[Bug c++/58477] [4.9 Regression] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sat Dec 14 18:28:22 2013 New Revision: 205991 URL: http://gcc.gnu.org/viewcvs?rev=205991root=gccview=rev Log: PR middle-end/58477 * cgraphclones.c (cgraph_clone_edge): Do not resolve speculative edges. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c
[Bug debug/59418] ICE in maybe_record_trace_start, at dwarf2cfi.c:2221
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59418 Ryan Mansfield rmansfield at qnx dot com changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Ryan Mansfield rmansfield at qnx dot com --- ICE started happening after rev205118 http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=205118
[Bug fortran/46641] Specification-expr checks and results with C_SIZEOF and SIZEOF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46641 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback since almost six months. Closing as FIXED. Please open a new PR if I have missed any remaining issue.
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 Bug 51605 depends on bug 51610, which changed state. Bug 51610 Summary: [OOP] Class container does not properly handle POINTER and TARGET http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/51610] [OOP] Class container does not properly handle POINTER and TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback since six months. Closing as FIXED. Please open a new PR if I have missed any remaining issue.
[Bug fortran/47399] [OOP] ICE with TBP of a PARAMETER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47399 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback since three months. Closing as FIXED. Please open a new PR if I have missed any remaining issue.
[Bug fortran/45824] Update expr.c's check_inquiry for C_SIZEOF, compiler_version/_options, etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45824 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback since almost six months. Closing as FIXED.
[Bug fortran/46641] Specification-expr checks and results with C_SIZEOF and SIZEOF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46641 Bug 46641 depends on bug 45824, which changed state. Bug 45824 Summary: Update expr.c's check_inquiry for C_SIZEOF, compiler_version/_options, etc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45824 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #2 from Markus Trippelsdorf octoploid at yandex dot com ---
Here's a reduced testcase that works without any gcda file:
markus@x4 testcase % test.ii
class A {
int m_fn1() const;
unsigned m_fn2() const;
};
class B {
public:
virtual void m_fn1();
};
class C final : B {
C();
virtual void m_fn2() { m_fn1(); }
};
int a;
unsigned A::m_fn2() const {
if (m_fn1())
return 0;
a = m_fn2();
}
C::C() {}
markus@x4 testcase % c++ -c -fprofile-use -O2 -std=c++11 test.ii
test.ii: In member function ‘virtual void C::m_fn2()’:
test.ii:19:9: internal compiler error: Segmentation fault
C::C() {}
[Bug debug/59510] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212 with -O2 -g --param=large-stack-frame-growth=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59510
Bug ID: 59510
Summary: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at
var-tracking.c:8212 with -O2 -g
--param=large-stack-frame-growth=1
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Created attachment 31441
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31441action=edit
autoreduced testcase
Compiler output:
$ gcc -O2 -g --param=large-stack-frame-growth=1 testcase.C
/home/smatz/build-205784-lto-fortran-checking-yes-rtl-df/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_types.h:
In function '_OI {anonymous}::copy(_II, _II, _OI) [with _II = char*; _OI =
{anonymous}::ostreambuf_iteratorchar]':
/home/smatz/build-205784-lto-fortran-checking-yes-rtl-df/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_types.h:200:3:
internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8212
0xf35d6c vt_expand_var_loc_chain
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8212
0xf35d6c vt_expand_loc_callback
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8408
0x933fd1 cselib_expand_value_rtx_1
/mnt/svn/gcc-trunk/gcc/cselib.c:1684
0x934f0e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/mnt/svn/gcc-trunk/gcc/cselib.c:1531
0xf3500c vt_expand_loc_callback
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8344
0x9340ca cselib_expand_value_rtx_1
/mnt/svn/gcc-trunk/gcc/cselib.c:1649
0x934f0e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/mnt/svn/gcc-trunk/gcc/cselib.c:1531
0xf35468 vt_expand_var_loc_chain
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8246
0xf35468 vt_expand_loc_callback
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8408
0x933fd1 cselib_expand_value_rtx_1
/mnt/svn/gcc-trunk/gcc/cselib.c:1684
0x934f0e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/mnt/svn/gcc-trunk/gcc/cselib.c:1531
0xf29b73 vt_expand_var_loc_chain
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8246
0xf29b73 vt_expand_1pvar
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8521
0xf29b73 emit_note_insn_var_location(variable_def**, emit_note_data_def*)
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8575
0xf3925b traverse_noresizeemit_note_data_def*, emit_note_insn_var_location
/mnt/svn/gcc-trunk/gcc/hash-table.h:928
0xf3925b traverseemit_note_data_def*, emit_note_insn_var_location
/mnt/svn/gcc-trunk/gcc/hash-table.h:950
0xf3925b emit_notes_for_changes
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8937
0xf39f01 emit_notes_in_bb
/mnt/svn/gcc-trunk/gcc/var-tracking.c:9382
0xf39f01 vt_emit_notes
/mnt/svn/gcc-trunk/gcc/var-tracking.c:9431
0xf3b026 variable_tracking_main_1
/mnt/svn/gcc-trunk/gcc/var-tracking.c:10292
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-205985-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-205985-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20131214 (experimental) (GCC)
Tested revisions:
r205985 - crash
4.8 r204890 - OK
[Bug c++/58477] [4.9 Regression] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sat Dec 14 22:08:48 2013 New Revision: 205993 URL: http://gcc.gnu.org/viewcvs?rev=205993root=gccview=rev Log: PR middle-end/58477 * ipa-prop.c (stmt_may_be_vtbl_ptr_store): Skip clobbers. * g++.dg/ipa/devirt-19.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-19.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51610] [OOP] Class container does not properly handle POINTER and TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) No feedback since six months. Closing as FIXED. Please open a new PR if I have missed any remaining issue. AFAICS, we still get the bogus error: target :: a, b, c 1 Error: Duplicate TARGET attribute specified at (1)
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 Bug 51605 depends on bug 51610, which changed state. Bug 51610 Summary: [OOP] Class container does not properly handle POINTER and TARGET http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c/55217] False -Wstrict-overflow warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
Michael Veksler mickey.veksler at gmail dot com changed:
What|Removed |Added
CC||mickey.veksler at gmail dot com
--- Comment #1 from Michael Veksler mickey.veksler at gmail dot com ---
(Strange that this hasn't been confirmed for over a year!)
I have a similar issue with gcc-4.8 with a slightly different test-case.
So first I looked into your test case. To me it seems that gcc-4.7 warning does
look strange here, but with gcc-4.8 things look better:
gcc -c -O2 -Wstrict-overflow=2 beta.c -std=c99
beta.c: In function ‘f’:
beta.c:7:20: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
if (r)
^
beta.c:10:17: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
for (int j = 0; j r; j++)
---
The first warning for if(r) makes sense.
However, the second warning does not make sense. Even after removing the 'if'
the warning stays:
---
void f(int n, int s)
{
int r = 1;
for (int i = 1; i n; i++)
if (r)
r++;
for (int j = 0; j r; j++)
h(s);
}
gamma.c:9:9: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
for (int j = 0; j r; j++)
---
It is as if gcc transforms the for loop to:
int j=0;
if (j = r) goto done; // --- does the warning come from here?
loop:
h(s);
j++
if (j r) goto loop;
done:
I assume that then gcc notices that r=1, unless it overflows, and hence
j=r must be false for the first j, i.e., j=0.
If this is what happens, then this is the wrong way to do it. If the same
expression is duplicated then -Wstrict-overflow should be emitted only if
it applies to both duplicates, or am I missing something?
[Bug c/55217] False -Wstrict-overflow warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #2 from Michael Veksler mickey.veksler at gmail dot com ---
A much more clear-cut, weird, and severe case:
$ cat delta.c
int bar();
void foo()
{
int stop= 0;
for (int i=10 ; i=0 !stop; --i) {
stop= bar();
}
}
$ gcc -c -O3 -Wstrict-overflow=3 delta.c -std=c99
delta.c: In function ‘foo’:
delta.c:5:22: warning: assuming signed overflow does not occur when changing X
+- C1 cmp C2 to X cmp C1 +- C2 [-Wstrict-overflow]
for (int i=10 ; i=0 !stop; --i) {
^
This make no sense at all and significantly lowers the usability of
-Wstrict-overflow=3. Either VRP or constant-propagation must have realized that
overflow is impossible, or does VRP come into play only after the warning is
emitted? Or maybe VRP can't do it because such reasoning requires induction?
Oh, and:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --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-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --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 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- There are 140 calls to generate_error in the library. I have begun an audit of these and see the design plan that was intended. I would like to stick to that design plan and not modify generate error. Most places are handled correctly. Generally speaking, after doing multiple groups of error checking these are checked by lines such as: if ((opp-common.flags IOPARM_LIBRETURN_MASK) == IOPARM_LIBRETURN_OK) This statement checks if all was OK before actually taking any actions. It is done this way for runtime efficiency. In short there are a few places where I need to clean up the code a little. I have started the patch, so will assign this bug to myself.
