[Bug lto/60981] New: lto-plugin configuration doesn't test for -static-libgcc (OSX gcc - clang)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 Bug ID: 60981 Summary: lto-plugin configuration doesn't test for -static-libgcc (OSX gcc - clang) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: tony.theodore at gmail dot com Created attachment 32690 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32690action=edit lto-plugin -static-libgcc configure.ac test Hi, When building on OSX, gcc is a symlink to clang and doesn't accept the -static-libgcc option. The attached patch basically copies the have_static_libs test from the top level configure.ac:1253 to the lto-plugin/configure.ac (removing the c++ parts) - it hasn't been tested as I don't have the right version of autoconf, but copying and modifying the corresponding section from configure works. Cheers, Tony
[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc - clang)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 --- Comment #1 from Tony Theodore tony.theodore at gmail dot com --- Created attachment 32691 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32691action=edit add -static-libgcc to lto-plugin/configure This is the modified lto-plugin/configure that has been tested.
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-28 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r203985.
[Bug pch/60982] New: Very long compilation of precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 Bug ID: 60982 Summary: Very long compilation of precompiled headers Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: georgthegreat at gmail dot com I'm trying to compile gcc-4.8.2 on powerpc64 to run on powerpc32. The problem is that I don't have sudo privileges on target machine, so I'm installing everything locally. I've all prerequisites preinstalled and gcc/g++-4.1.2. I configure with the following command: ./configure --prefix=/gpfs/data/chernyshov/chroot --enable-languages=c,c++ --enable-shared --with-gmp=/gpfs/data/chernyshov/chroot --with-mpc=/gpfs/data/chernyshov/chroot --with-mpfr=/gpfs/data/chernyshov/chroot During compilation (as far, as I understand, this is libstdc++ compilation), the following command hangs (I waited for 560 minutes for it's completion): /gpfs/data/chernyshov/contrib/gcc-4.8.2/host-powerpc64-unknown-linux-gnu/gcc/xgcc -shared-libgcc -B/gpfs/data/chernyshov/contrib/gcc-4.8.2/host-powerpc64-unknown-linux-gnu/gcc -nostdinc++ -L/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/bin/ -B/gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/lib/ -isystem /gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/include -isystem /gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/sys-include -x c++-header -nostdinc++ -I/gpfs/data/chernyshov/chroot/include -D_GNU_SOURCE -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/gpfs/data/chernyshov/contrib/gcc-4.8.2/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /gpfs/data/chernyshov/contrib/gcc-4.8.2/libstdc++-v3/include/precompiled/stdc++.h \ -o powerpc64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Note I think this code is invalid due to the struct not having a size.
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #3)
Note I think this code is invalid due to the struct not having a size.
Making the array non-empty makes no difference:
struct x0
{
x0 () = default;
};
struct x1
{
x0 x2[1];
void x3 ()
{
x1 ();
}
};
g++ -c -std=c++11 t.ii
t.ii: In member function ‘void x1::x3()’:
t.ii:10:13: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.c:7447
... same as above.
[Bug c/60983] New: Fix for pr60114 introduced FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60983 Bug ID: 60983 Summary: Fix for pr60114 introduced FAILs Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Commit 209794, which fixes pr60114, has introduced some new FAILs on ARM/AArch64 targets. The compiler does emit warnings, but not the ones expected by the test: Problems are reported for lines 7, 8, 21, 22, 23, 25, which actually report: warning: large integer implicitly truncated to unsigned type [-Woverflow] instead of the expected: warning: overflow in implicit constant conversion
[Bug pch/60982] Very long compilation of precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- How much RAM do you have? Is the machine swapping while running that command? How much memory is the cc1plus process using?
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #4 from Thomas Sanchez thomas.sanchz at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
N.B. the std::move in Manager::cancelConnection is redundant, the return
value from cancel_connection is already an rvalue.
Yes, I know, the problem is I have some hard time to avoid doing this as it
is more for me and what I expect the compiler to do or the semantics I want
the code to have :)
OK, but it makes the code worse. Here the compiler will elide the move
constructor (aka return value optimisation):
auto future = cancel_connection(c);
Whereas here the compiler cannot do that and must call a move constructor:
auto future = std::move(cancel_connection(c));
I did not meant to say I should continue, far from here :) Thank for the
notice!
Anyway, I pushed the actual code in this branch:
https://github.com/daedric/httpp/tree/bug-promise-test
I was able to do a small test that can *sometimes* reproduce the bug:
https://github.com/daedric/httpp/blob/bug-promise-test/tests/client/promise.cpp
Since I was able to trigger the problem, here are what you asked for:
From the get side, (from here
https://github.com/daedric/httpp/blob/bug-promise-test/src/httpp/http/client/Manager.cpp#L113)
(gdb) print future
$1 = {
std::__basic_futurevoid = {
std::__future_base = {No data fields},
members of std::__basic_futurevoid:
_M_state = std::shared_ptr (count 2, weak 0) 0x805468
}, No data fields}
(gdb) print promise
$2 = {
_M_future = std::shared_ptr (count 2, weak 0) 0x805468,
_M_storage = std::unique_ptrstd::__future_base::_Resultvoid containing
0x805780
}
(gdb) print promise
$3 = (std::promisevoid *) 0x7fffce90
From the thread calling the pthread_once:
#4 0x00500d67 in std::promisevoid::set_value (this=0x7fffce90)
at /usr/include/c++/4.8/future:1197
1197_M_future-_M_set_result(std::move(__setter));
(gdb) print *this
$4 = {
_M_future = std::shared_ptr (count 2, weak 0) 0x805468,
_M_storage = std::unique_ptrstd::__future_base::_Resultvoid containing
0x805780
}
This is seems to be correct.
This has been produced with commit: 850ebba9a72d102b54de6912e820889618a4f30d
I'm testing now with the lambdas replaced :)
http://reproducible.io/
[Bug pch/60982] Very long compilation of precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 --- Comment #2 from Yuriy Chernyshov georgthegreat at gmail dot com --- Memory usage is 0.1%. Building host has 32g of RAM.
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #5 from Thomas Sanchez thomas.sanchz at gmail dot com ---
With my previous mail, the link I added was because I wanted to ask that if you
were not able to reproduce the problem I could use CARE to recreate the
environment I'm running my test.
With lambda replaced (commit fd8b4a8ce7847dc561c937e2a3c80db0d735835c) the
seems to be triggered a bit less often however, I do have a segfault in
malloc_consolidate, I'll come back onto this later.
Manager.cpp:121
(gdb) print future
$1 = {
std::__basic_futurevoid = {
std::__future_base = {No data fields},
members of std::__basic_futurevoid:
_M_state = std::shared_ptr (count 2, weak 0) 0x812468
}, No data fields}
(gdb) print promise
$2 = {
_M_future = std::shared_ptr (count 2, weak 0) 0x812468,
_M_storage = std::unique_ptrstd::__future_base::_Resultvoid containing
0x812780
}
Manager.cpp:87
(gdb) print promise
$3 = (std::promisevoid ) @0x7fffce40: {
_M_future = std::shared_ptr (count 2, weak 0) 0x812468,
_M_storage = std::unique_ptrstd::__future_base::_Resultvoid containing
0x812780
}
This also seems ok.
About the segfault on the malloc, I think the problems are related, I guess it
is possible that the pthread_once does not always hangs and who knows what mess
it could cause in the memory.
In case you interested in the segfault, here is the trace:
Program received signal SIGSEGV, Segmentation fault.
malloc_consolidate (av=av@entry=0x7722c760 main_arena) at malloc.c:4157
4157malloc.c: No such file or directory.
(gdb) bt
#0 malloc_consolidate (av=av@entry=0x7722c760 main_arena) at
malloc.c:4157
#1 0x76eedc38 in _int_malloc (av=0x7722c760 main_arena,
bytes=7288) at malloc.c:3423
#2 0x76ef05f0 in __GI___libc_malloc (bytes=7288) at malloc.c:2891
#3 0x77984d8f in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4 0x77984ecf in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5 0x77985cbd in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6 0x00506a08 in HTTPP::HTTP::client::detail::Manager::Manager
(this=0x811eb0, io=..., dispatch=...) at
/home/daedric/perso/httpp/src/httpp/http/client/Manager.cpp:52
#7 0x004ef61b in HTTPP::HttpClient::HttpClient (this=0x7fffcfb0,
nb_thread=1, name=) at /home/daedric/perso/httpp/src/httpp/HttpClient.cpp:38
The segfault on the call of curl_multi_init and this one occurs in the
constructor. I was not able to check with valgrind so far if a failed
instanciation occurs after a trace about an invalid call_once/pthread_once
[Bug c/60983] Fix for pr60114 introduced FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60983 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-28 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed, this is because on arm/aarch64 chars are unsigned by default. Best fix is to add -fsigned char to testcase. Will post a patch soon.
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #6 from Thomas Sanchez thomas.sanchz at gmail dot com --- Last comment on myself: I got some errors relates to the promise with valgrind but they do not cause an hangs ==30999== Thread 2: ==30999== Invalid read of size 4 ==30999==at 0x4E44A91: pthread_once (pthread_once.S:111) ==30999==by 0x4F4274: __gthread_once(int*, void (*)()) (gthr-default.h:699) ==30999==by 0x4FADBC: void std::call_oncevoid (std::__future_base::_State_base::*)(std::functionstd::unique_ptrstd::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter (), bool), std::__future_base::_State_base* const, std::reference_wrapperstd::functionstd::unique_ptrstd::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter () , std::reference_wrapperbool (std::once_flag, void (std::__future_base::_State_base::*)(std::functionstd::unique_ptrstd::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter (), bool), std::__future_base::_State_base* const, std::reference_wrapperstd::functionstd::unique_ptrstd::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter () , std::reference_wrapperbool) (mutex:786) ==30999==by 0x4F75A2: std::__future_base::_State_base::_M_set_result(std::functionstd::unique_ptrstd::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter (), bool) (future:358) ==30999==by 0x50B666: std::promisevoid::set_value() (future:1197) ==30999==by 0x506E1F: HTTPP::HTTP::client::detail::Manager::check_handles(std::promisevoid) (Manager.cpp:87) ==30999==by 0x51D9A6: void std::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid)::operator()std::promisevoid, void(HTTPP::HTTP::client::detail::Manager*, std::promisevoid) const (in /home/daedric/perso/httpp/build/tests/client/Test_Client_promise) ==30999==by 0x51CFBE: void std::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid )::__callvoid, , 0ul, 1ul(std::tuple, std::_Index_tuple0ul, 1ul) (functional:1296) ==30999==by 0x51C4FF: void std::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid )::operator(), void() (functional:1355) ==30999==by 0x51B594: void boost::asio::asio_handler_invokestd::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid ) (std::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid ), ...) (handler_invoke_hook.hpp:64) ==30999==by 0x519E81: void boost_asio_handler_invoke_helpers::invokestd::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid ), std::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid ) (std::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid ), std::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid )) (handler_invoke_helpers.hpp:37) ==30999==by 0x51B6CE: boost::asio::detail::completion_handlerstd::_Bindstd::_Mem_fnvoid (HTTPP::HTTP::client::detail::Manager::*)(std::promisevoid) (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapperstd::promisevoid ) ::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const, unsigned long) (completion_handler.hpp:68) ==30999== Address 0xdbd3b54 is 132 bytes inside a block of size 136 free'd ==30999==at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==30999==by 0x504C41: __gnu_cxx::new_allocatorstd::_Sp_counted_ptr_inplacestd::__future_base::_State_base, std::allocatorstd::__future_base::_State_base, (__gnu_cxx::_Lock_policy)2 ::deallocate(std::_Sp_counted_ptr_inplacestd::__future_base::_State_base, std::allocatorstd::__future_base::_State_base, (__gnu_cxx::_Lock_policy)2*, unsigned long) (new_allocator.h:110) ==30999==by 0x5045F2: std::allocator_traitsstd::allocatorstd::_Sp_counted_ptr_inplacestd::__future_base::_State_base, std::allocatorstd::__future_base::_State_base, (__gnu_cxx::_Lock_policy)2 ::deallocate(std::allocatorstd::_Sp_counted_ptr_inplacestd::__future_base::_State_base, std::allocatorstd::__future_base::_State_base, (__gnu_cxx::_Lock_policy)2 , std::_Sp_counted_ptr_inplacestd::__future_base::_State_base,
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Thomas Sanchez from comment #4) Anyway, I pushed the actual code in this branch: https://github.com/daedric/httpp/tree/bug-promise-test I was able to do a small test that can *sometimes* reproduce the bug: https://github.com/daedric/httpp/blob/bug-promise-test/tests/client/promise. cpp Great, thanks, I will look into it.
[Bug rtl-optimization/60866] [4.7/4.8/4.9/4.10 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org --- Comment #3 from Andrey Belevantsev abel at gcc dot gnu.org --- Created attachment 32692 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32692action=edit draft patch An interesting case so I'd leave more detailed notes. We are scheduling a region that has a diamond like this: bb 3 -- |\ bb 4\ /\ \ bb 5 bb 6 / \// bb 7 -- After scheduling bb 3 we proceed to bb 4 and bb 7 simultaneously. Bbs 5 and 6 have identical insns. While having a fence at the end of bb 4, we unify these insns to one and get empty bbs 5 and 6 at once. While simplifying this, we end up with a conditional jump ending bb 4 turning into an unconditional one leading to bb 7 (via redirect_edge_and_branch). This jump is the new insn so should be initialized. We try to get a seqno for this jump from surrounding unscheduled code (via get_seqno_for_a_jump), but both bbs 4 and 7 are already completely scheduled. Thus we ICE. The only unscheduled insn in this region is the old conditional jump. But it is no longer with us while we're trying to init the new jump it turned into. The easy solution is to remove the assert and to change it into something like seqno = 42;. This fixes the test but we will never be able to catch bugs in this function again. The preferred solution will be to pass down the old jump seqno to the initializing function so it would take it as the new jump seqno only in this particular case. That means changing a number of sel_init_new_insn callers. But, if we are now allowed to have default parameters (do we?), this simplifies things. Attached is the draft patch (the function comments is not yet updated, C++ default parameters are used).
[Bug bootstrap/60984] New: AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 Bug ID: 60984 Summary: AIX: gcc-4.9.0 bootstrap fails in stage-2 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tgard at opentext dot com Created attachment 32693 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32693action=edit Error output, config.log, config.status /builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/./prev-gcc/xg++ -B/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/./prev-gcc/ -B/usr/local/gcc-4.9.0/powerpc-ibm-aix6.1.0.0/bin/ -nostdinc++ -B/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs -B/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/libsupc++/.libs -I/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/include/powerpc-ibm-aix6.1.0.0 -I/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/include -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/libstdc++-v3/libsupc++ -L/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs -L/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/prev-powerpc-ibm-aix6.1.0.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/. -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../include -I./../intl -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libcpp/include -I/usr/local/lib32-static/include -I/usr/local/lib32-static/include -I/usr/local/lib32-static/include -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libdecnumber -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/../libbacktrace-o tree-ssa-address.o -MT tree-ssa-address.o -MMD -MP -MF ./.deps/tree-ssa-address.TPo /builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/tree-ssa-address.c In file included from /builds/gbgbuild/bld/gcc/gcc-4.9.0/gcc/tree-ssa-address.c:1024:0: ./gt-tree-ssa-address.h:86:2: internal compiler error: in operator[], at vec.h:735 }; ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [tree-ssa-address.o] Error 1 make[3]: Leaving directory `/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/builds/gbgbuild/bld/gcc/stbldap01/obj_stbldap01-4.9.0' make: *** [all] Error 2
[Bug lto/58528] lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528 Viktor Ostashevskyi ostash at ostash dot kiev.ua changed: What|Removed |Added CC||ostash at ostash dot kiev.ua --- Comment #7 from Viktor Ostashevskyi ostash at ostash dot kiev.ua --- I managed to trigger this bug too: lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/atse_git/ostash/tc48/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-4.8-20140313/configure --enable-bootstrap --enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit --disable-fixed-point --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-libstdcxx-time --disable-libquadmath --disable-libquadmath-support --enable-linux-futex --enable-lto --disable-multiarch --disable-multilib --disable-nls --enable-plugin --enable-secureplt --disable-sjlj-exceptions --enable-threads=posix --enable-tls --with-build-config=bootstrap-lto --with-gnu-as --with-gnu-ld --with-linker-hash-style=gnu --with-system-zlib --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu Thread model: posix gcc version 4.8.3 20140313 (prerelease) (GCC) I can't provide sources unfortunately.
[Bug c/60983] Fix for pr60114 introduced FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60983 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Instead use 'signed char' types please.
[Bug pch/60982] Very long compilation of precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- As a workaround you can configure with --disable-libstdcxx-pch (the generated PCHs are not too useful anyway).
[Bug pch/60982] Very long compilation of precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982 --- Comment #4 from Yuriy Chernyshov georgthegreat at gmail dot com --- Thanks, Richard and Jonathan (you both gave me the same solution). Hope, this helps. I'll post the results here, once I'll get them.
[Bug tree-optimization/60979] [4.9/4.10 Regression] ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544, w/ -O -ftree-loop-linear or -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60979 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-28 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. I will have a look.
[Bug rtl-optimization/60947] [4.9/4.10 Regression] Unable to handle kernel paging request (linux kernel 2.6.28.9) with gcc 4.9 release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947 --- Comment #10 from YuFan yufan8.chen at gmail dot com --- After more tests, I figure out the issue is caused by the commit: SVN revision: r206552 | amker | 2014-01-11 17:33:39 +0800 (六, 11 1月 2014) | 7 lines * tree-ssa-loop-ivopts.c (iv_ca_narrow): New parameter. Start narrowing with START. Apply candidate-use pair and check overall cost in narrowing. (iv_ca_prune): Pass new argument.
[Bug c++/60978] -Wenum-compare warns too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-28 Summary|[4.9 Regression]|-Wenum-compare warns too |-Wenum-compare warns too|eagerly |eagerly | Ever confirmed|0 |1 Known to fail||4.3.6 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Warns since forever (checked up to GCC 4.3.x), confirmed.
[Bug preprocessor/60975] -Wvariadic-macros does not print warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60975 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Please send patches to gcc-patc...@gcc.gnu.org and specify how you tested it Bootstrapped and tested on .
[Bug ipa/60973] Invalid propagation of a tail call in devirt pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Target||h8300-elf
CC||hubicka at gcc dot gnu.org,
||jamborm at gcc dot gnu.org
Component|tree-optimization |ipa
Summary|Invalid propagation of a|Invalid propagation of a
|tail call in copyrename2|tail call in devirt pass
|pass|
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
It's not copyrename (that's just the first dump you see it) but inlining.
Inlining probably needs to clear [tailcall] from all inlined stmts unless
it wants to prove the tailcall is still possible.
Thus,
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 209782)
+++ gcc/tree-inline.c (working copy)
@@ -1485,6 +1489,11 @@ remap_gimple_stmt (gimple stmt, copy_bod
/* Create a new deep copy of the statement. */
copy = gimple_copy (stmt);
+ /* Clear flags that need revisiting. */
+ if (is_gimple_call (copy)
+ gimple_call_tail_p (copy))
+ gimple_call_set_tail (copy, false);
+
/* Remap the region numbers for __builtin_eh_{pointer,filter},
RESX and EH_DISPATCH. */
if (id-eh_map)
not sure if GF_CALL_FROM_THUNK needs similar handling.
The bug is probably not h8300-elf specific (but usually tailcall expansion
fails as it re-checks the validity of the transform - and IIRC that is
required, so it may even be a h8300-elf backend bug).
[Bug debug/60929] [4.8/4.9 regression] ICE in get_ref_die_offset, at dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.10.0 Summary|[4.8/4.9/4.10 regression] |[4.8/4.9 regression] ICE |ICE in get_ref_die_offset, |in get_ref_die_offset, at |at dwarf2out.c |dwarf2out.c Known to fail||4.8.2, 4.9.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug driver/60968] [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |4.9.1
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug c++/51424] [C++11] G++ should diagnose self-delegating constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- I seem to remember that the reason why I didn't close it completely at the time is that we may want to extend the diagnostic to cover non-trivial cycles too... Opinions? Could also be a separate bug, that for sure.
[Bug c++/51424] [C++11] G++ should diagnose self-delegating constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424 --- Comment #8 from Ville Voutilainen ville.voutilainen at gmail dot com --- My 2 cents is to open a separate bug if we want diagnostics for the more elaborate self-delegating cases.
[Bug tree-optimization/60979] [4.9/4.10 Regression] ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544, w/ -O -ftree-loop-linear or -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60979 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- create_single_exit_edge uses make_forwarder_block which doesn't really do things in a way that works for incoming abnormal edges. I can fix it by constraining SCOP detection. Index: gcc/graphite-scop-detection.c === --- gcc/graphite-scop-detection.c (revision 209849) +++ gcc/graphite-scop-detection.c (working copy) @@ -474,8 +474,10 @@ scopdet_basic_block_info (basic_block bb result.exits = false; /* Mark bbs terminating a SESE region difficult, if they start -a condition. */ - if (!single_succ_p (bb)) +a condition or if the block it exits to cannot be split +with make_forwarder_block. */ + if (!single_succ_p (bb) + || bb_has_abnormal_pred (single_succ (bb))) result.difficult = true; else result.exit = single_succ (bb);
[Bug c++/59120] [c++11] ICE with invalid template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59120 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Apr 28 12:32:06 2014 New Revision: 209857 URL: http://gcc.gnu.org/viewcvs?rev=209857root=gccview=rev Log: /cp 2014-04-28 Paolo Carlini paolo.carl...@oracle.com PR c++/59120 * parser.c (cp_parser_alias_declaration): Check return value of cp_parser_require. /testsuite 2014-04-28 Paolo Carlini paolo.carl...@oracle.com PR c++/59120 * g++.dg/cpp0x/alias-decl-43.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59120] [c++11] ICE with invalid template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59120 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c/60983] Fix for pr60114 introduced FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60983 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from ktkachov at gcc dot gnu.org --- Testcase fixed on trunk.
[Bug c/60983] Fix for pr60114 introduced FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60983 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Apr 28 12:42:54 2014 New Revision: 209858 URL: http://gcc.gnu.org/viewcvs?rev=209858root=gccview=rev Log: [ARM/AArch64] Use signed chars in gcc.dg/pr60114.c. PR c/60983 * gcc.dg/pr60114.c: Use signed chars. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr60114.c
[Bug c/60985] New: _mm_blendv_pd requires the '-msse4.1' option to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60985
Bug ID: 60985
Summary: _mm_blendv_pd requires the '-msse4.1' option to
compile
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jean-charles.pa...@ens-cachan.fr
GCC (4.9.0) fails to compile a call to '_mm_blendv_pd' intrinsic unless we add
the '-msse4.1' gcc option.
End code - [test_blendv_pd.c]
#include smmintrin.h
#include emmintrin.h
int main(int argc, const char *argv[])
{
__m128d a = _mm_setzero_pd (),
b= _mm_setzero_pd (),
mask = _mm_setzero_pd ();
__m128d r = _mm_blendv_pd (a, b, mask);
return 0;
}
End code - [test_blendv_pd.c]
Command line: gcc test_blendv_pd.c
GCC output:
In file included from test_blendv_pd.c:2:0:
test_blendv_pd.c: In function 'main':
/opt/gcc-4.9.0/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/smmintrin.h:229:1:
error: inlining failed in call to always_inline '_mm_blendv_pd': target
specific option mismatch
_mm_blendv_pd (__m128d __X, __m128d __Y, __m128d __M)
^
test_blendv_pd.c:12:10: error: called from here
__m128d r = _mm_blendv_pd (a, b, mask);
In case of the '_mm_blend_pd (__m128d, __m128d, int)' function, gcc produces
the following error message:
error: '__builtin_ia32_blendpd' needs isa option -m32 -msse4.1
It would be great to have the same error message for '_mm_blendv'.
[Bug tree-optimization/60979] [4.9 Regression] ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544, w/ -O -ftree-loop-linear or -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60979 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Apr 28 13:13:50 2014 New Revision: 209859 URL: http://gcc.gnu.org/viewcvs?rev=209859root=gccview=rev Log: 2014-04-28 Richard Biener rguent...@suse.de PR tree-optimization/60979 * graphite-scop-detection.c (scopdet_basic_block_info): Reject SCOPs that end in a block with a successor with abnormal predecessors. * gcc.dg/graphite/pr60979.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr60979.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60986] New: Wrong handling of const variables in lambda functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60986 Bug ID: 60986 Summary: Wrong handling of const variables in lambda functions Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: physik3 at gmx dot net The code in the attachment compiles, but behaves in a strange way. Output is a = 42 b = 0 b = 0 b = 42 expected (and achieved if the function is not templated): a = 42 b = 42 b = 42 b = 42
[Bug c/60985] _mm_blendv_pd requires the '-msse4.1' option to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60985 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- The -m32 part of the warning seems bogus.
[Bug tree-optimization/60902] [4.9 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 --- Comment #34 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Mon Apr 28 13:38:19 2014 New Revision: 209860 URL: http://gcc.gnu.org/viewcvs?rev=209860root=gccview=rev Log: PR tree-optimization/60902 * tree-ssa-threadedge.c (record_temporary_equivalences_from_stmts_at_dest): Only iterate over real defs when invalidating outputs from statements that do not produce useful outputs for threading. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug c++/60978] -Wenum-compare warns too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978 --- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Richard Biener from comment #6) Warns since forever (checked up to GCC 4.3.x), confirmed. Interesting. In my non-reduced test case, the warning is new with gcc-4.9.
[Bug bootstrap/60984] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- I have been bootstrapping GCC trunk and 4.9 on AIX 7.1 without any failures.
[Bug middle-end/60957] [4.9/4.10 Regression] Bogus error: array subscript is above array bounds [-Werror=array-bounds]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60957 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |INVALID --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Agreed. Nothing guards the reference to size_map[old_width].
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for soft-float on arm-*-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.3.4 --- Comment #18 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- fixed.
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Apr 28 14:36:13 2014 New Revision: 209863 URL: http://gcc.gnu.org/viewcvs?rev=209863root=gccview=rev Log: 2014-04-28 Richard Biener rguent...@suse.de PR middle-end/60092 * builtins.def (DEF_C11_BUILTIN): Add. (BUILT_IN_ALIGNED_ALLOC): Likewise. * coretypes.h (enum function_class): Add function_c11_misc. * tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Handle BUILT_IN_ALIGNED_ALLOC like BUILT_IN_MALLOC. (call_may_clobber_ref_p_1): Likewise. * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Likewise. (mark_all_reaching_defs_necessary_1): Likewise. (propagate_necessity): Likewise. (eliminate_unnecessary_stmts): Likewise. * tree-ssa-ccp.c (evaluate_stmt): Handle BUILT_IN_ALIGNED_ALLOC. ada/ * gcc-interface/utils.c: Define flag_isoc11. lto/ * lto-lang.c: Define flag_isoc11. * gcc.dg/tree-ssa/alias-32.c: New testcase. * gcc.dg/vect/pr60092.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-32.c trunk/gcc/testsuite/gcc.dg/vect/pr60092.c Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c trunk/gcc/builtins.def trunk/gcc/coretypes.h trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-lang.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-dce.c
[Bug c++/60986] Wrong handling of const variables in lambda functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60986 --- Comment #1 from physik3 at gmx dot net --- Created attachment 32694 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32694action=edit file containing the code
[Bug libstdc++/60987] libstdc++ header file tr1/regex causes clang++ compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60987 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0 Known to fail||4.10.0, 4.6.0, 4.7.0, ||4.8.0, 4.9.0
[Bug libstdc++/60987] New: libstdc++ header file tr1/regex causes clang++ compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60987
Bug ID: 60987
Summary: libstdc++ header file tr1/regex causes clang++
compilation error
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
It seems clang++ is more pedantic on the syntax it accepts for initializing
arrays of strings. The tr1/regex header file (gcc 4.6 thru trunk) contains an
array initialization that clang++ doesn't accept, but g++ does:
bergner@bns:~ cat bug.cc
#include tr1/regex
bergner@bns:~ /home/bergner/llvm/llvm-install/bin/clang++ -c bug.cc
In file included from bug.cc:1:
/home/bergner/gcc/install/gcc-fsf-mainline-build/include/c++/4.10.0/tr1:685:24:
error: array
initializer must be an initializer list
const char* const __wb[] = w;
^
/home/bergner/gcc/install/gcc-fsf-mainline-build/include/c++/4.10.0/tr1:695:24:
error: array
initializer must be an initializer list
const char* const __bb[] = blank;
^
2 errors generated.
The following patch is enough to quiet the clang++ error messages:
Index: libstdc++-v3/include/tr1/regex
===
--- libstdc++-v3/include/tr1/regex(revision 209382)
+++ libstdc++-v3/include/tr1/regex(working copy)
@@ -682,7 +682,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// special case of underscore in [[:w:]]
if (__c == __ctype.widen('_'))
{
- const char* const __wb[] = w;
+ const char* const __wb[] = {w};
char_class_type __wt = this-lookup_classname(__wb,
__wb + sizeof(__wb));
if (__f | __wt)
@@ -692,7 +692,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// special case of [[:space:]] in [[:blank:]]
if (__c == __ctype.isspace(__c))
{
- const char* const __bb[] = blank;
+ const char* const __bb[] = {blank};
char_class_type __bt = this-lookup_classname(__bb,
__bb + sizeof(__bb));
if (__f | __bt)
[Bug libstdc++/60987] libstdc++ header file tr1/regex causes clang++ compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60987 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed last week, but why do people keep including that header anyway?! *** This bug has been marked as a duplicate of bug 60958 ***
[Bug libstdc++/60958] Initialization of arrays in tr1/regex ill-formed or with undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60958 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 60987 has been marked as a duplicate of this bug. ***
[Bug c/60988] New: transparent_union doesn't appear in the gcc manual index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60988 Bug ID: 60988 Summary: transparent_union doesn't appear in the gcc manual index Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org I expected to find some mention of transparent_union in the index, but did not. See info gcc, then i transparent_union RET.
[Bug tree-optimization/60989] New: automatic increase of global array for vectorization doesn't work due to flag_section_anchors==0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60989
Bug ID: 60989
Summary: automatic increase of global array for vectorization
doesn't work due to flag_section_anchors==0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target x86_64-linux
Following simple test case:
#define N 64
#define ALIGN // __attribute__((aligned(64)))
int a[N] ALIGN;
int b[N] ALIGN;
main()
{
int i;
for (i = 0; i N; i++)
a[i] = b[i] + 1;
}
If I leave the ALIGN commented out I get really horrible manual alignment
prologue code like
-O3 -mavx512f
.cfi_startproc
movl$a, %eax
andl$63, %eax
shrq$2, %rax
negq%rax
andl$15, %eax
je .L7
movlb(%rip), %edi
cmpl$1, %eax
leal1(%rdi), %edx
movl%edx, a(%rip)
je .L8
...
lots of repeats upto 63
With ALIGN it's a nice short perfectly vectorized loop.
It seems the automatic alignment of global variables doesn't work anymore.
I checked the increase_alignment/ipa_increase_alignment pass in
tree-vectorize.c and both don't run because flag_section_anchors is 0 in the
gate.
I'm not fully sure what the flag means?
[Bug tree-optimization/60989] automatic increase of global array for vectorization doesn't work due to flag_section_anchors==0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60989 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- You need C++ or -fno-common. Common variables really can't have alignment increased by the compiler.
[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org --- Comment #4 from fabien at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #2) The regression was caused by r181359 Fabien, could you take a look please? I think the code is valid. Thanks, I will look into it.
[Bug bootstrap/60984] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-ibm-aix6.1 |powerpc-ibm-aix* Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-28 CC||rguenth at gcc dot gnu.org Host|powerpc-ibm-aix6.1 |powerpc-ibm-aix* Target Milestone|--- |4.9.1 Ever confirmed|0 |1 Build|powerpc-ibm-aix6.1 |powerpc-ibm-aix* --- Comment #2 from David Edelsohn dje at gcc dot gnu.org --- Okay, I can confirm this now. Bootstrap is working on trunk and was working at the point of the branch, so this is due to some 4.9-specific patch.
[Bug bootstrap/60984] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #3 from David Edelsohn dje at gcc dot gnu.org ---
731 templatetypename T, typename A
732 inline T
733 vecT, A, vl_embed::operator[] (unsigned ix)
734 {
735 gcc_checking_assert (ix m_vecpfx.m_num);
736 return m_vecdata[ix];
737 }
3153 gcc_checking_assert (true_predicate_p
((*info-entry)[0].predicate));
[Bug c++/60986] Wrong handling of const variables in lambda functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60986 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- It seems to be fixed in gcc 4.7.3 and in all newer compiler versions.
[Bug c++/60986] Wrong handling of const variables in lambda functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60986 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.3 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Indeed, thanks Daniel
[Bug ipa/60990] New: [4.9/4.10 Regression] ICE: in try_make_edge_direct_virtual_call, at ipa-prop.c:2796 with -O3 -fno-early-inlining -fno-ipa-cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60990 Bug ID: 60990 Summary: [4.9/4.10 Regression] ICE: in try_make_edge_direct_virtual_call, at ipa-prop.c:2796 with -O3 -fno-early-inlining -fno-ipa-cp Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32695 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32695action=edit preprocessed source (g++.dg/ipa/pr60600.C) Compiler output: $ gcc -O3 -fno-early-inlining -fno-ipa-cp pr60600.C pr60600.C:31:1: internal compiler error: in try_make_edge_direct_virtual_call, at ipa-prop.c:2796 } ^ 0xb24099 try_make_edge_direct_virtual_call /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2795 0xb24099 update_indirect_edges_after_inlining /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2851 0xb24099 propagate_info_to_inlined_callees /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2923 0xb239ee propagate_info_to_inlined_callees /mnt/svn/gcc-trunk/gcc/ipa-prop.c:2927 0x1538dac inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*, int*, bool) /mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:277 0x1538203 recursive_inlining /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1400 0x1538203 inline_small_functions /mnt/svn/gcc-trunk/gcc/ipa-inline.c:1772 0x1538203 ipa_inline /mnt/svn/gcc-trunk/gcc/ipa-inline.c:2185 0x1538203 execute /mnt/svn/gcc-trunk/gcc/ipa-inline.c:2546 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-209821-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.10.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-209821-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.10.0 20140426 (experimental) (GCC)
[Bug bootstrap/60984] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from David Edelsohn dje at gcc dot gnu.org --- AIX bootstraps at the gcc-4_9-branch creation point, but fails at GCC 4.9.0 release point. Trunk also bootstraps successfully. I am trying to bisect. r209304 okay r209518 fail
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #4 from Chernyshev Viacheslav astellar at ro dot ru --- After a series of tests I'm pretty sure that it is not a problem of g++, but libstdc++. Let me explain why do I think so. First, I was not able to reduce real life case to reasonably small subset that does not depend on external libs at least. So I've decided to test explicit template instantiation of std::map for multiple combination of integer types as key and value. File that I've used is attached as test.cpp. Overall pattern was the same. After that I realized that results depend on actual libstdc++ includes and I compare apples with oranges. So, I've used these commands to get preprocessed dump: - g++-4.8 -std=gnu++11 -O0 -E -P std_map.cpp preprocessed_48.cpp - g++-4.9 -std=gnu++11 -O0 -E -P std_map.cpp preprocessed_49.cpp After that I've compiled both files with g++-4.8 first and g++-4.9 second to compare results. And it turned out that they are nearly the same for both compilers depending on what file I compile. ftime-reports are in attachments. I understand that it is not a bug per se, but compilation time for my project that uses STL containers a lot jumped from 15 minutes to 40 minutes mark, and it would be nice to reduce it back somehow.
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #5 from Chernyshev Viacheslav astellar at ro dot ru --- Created attachment 32696 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32696action=edit Test file used
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #6 from Chernyshev Viacheslav astellar at ro dot ru --- Created attachment 32697 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32697action=edit ftime-report, preprocessed by 4.8.2, compiled by 4.8.2
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #7 from Chernyshev Viacheslav astellar at ro dot ru --- Created attachment 32698 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32698action=edit ftime-report, preprocessed by 4.8.2, compiled by 4.9.0
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #8 from Chernyshev Viacheslav astellar at ro dot ru --- Created attachment 32699 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32699action=edit ftime-report, preprocessed by 4.9.0, compiled by 4.8.2
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #9 from Chernyshev Viacheslav astellar at ro dot ru --- Created attachment 32700 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32700action=edit ftime-report, preprocessed by 4.9.0, compiled by 4.9.0
[Bug target/60991] New: [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
Bug ID: 60991
Summary: [avr] Stack corruption when using 24-bit integers
__int24 or __memx pointers in large stack frame
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: johnst...@inn-soft.com
Both avr-gcc 4.8.1 and 4.7.2 corrupt the stack when using 24-bit integers in a
large stack frame (= approximately 64 bytes) where the integer is stored at
the end of the stack frame such that it is normally out of reach of the STD
Y+q instruction. The below example demonstrates the problem. While the
example appears pedantic, it becomes a real problem when a program is
aggressively inlined through multiple layers of complicated functions that are
called only once, or when an array is allocated on the stack.
Note this problem exists with both __int24 data type and __memx pointers.
Steps I used to reproduce:
1. Create new AVR GCC C Executable project in Atmel Studio 6.1 or 6.2 beta.
6.2 beta uses avr-gcc 4.8.1 and 6.1 uses avr-gcc 4.7.2.
2. Target is ATxmega256A3U but I should think any target will work (but
untested). I use default compiler settings which gave command lines of:
C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8
GCC\Native\3.4.1051\avr8-gnu-toolchain\bin\avr-gcc.exe -x c -funsigned-char
-funsigned-bitfields -DDEBUG -O1 -ffunction-sections -fdata-sections
-fpack-struct -fshort-enums -mrelax -g2 -Wall -mmcu=atxmega256a3u -c -std=gnu99
-MD -MP -MF CrashTest.d -MTCrashTest.d -MTCrashTest.o -o CrashTest.o
.././CrashTest.c
C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8
GCC\Native\3.4.1051\avr8-gnu-toolchain\bin\avr-gcc.exe -o CrashTest.elf
CrashTest.o -Wl,-Map=CrashTest.map -Wl,--start-group -Wl,-lm
-Wl,--end-group -Wl,--gc-sections -mrelax -mmcu=atxmega256a3u
3. Use this code:
#include avr/wdt.h
__attribute__((__noinline__)) void Blowup(void) {
#define SZ 62
volatile char junk[SZ];
junk[0] = 5;
junk[SZ-1] = 6;
volatile __int24 staticConfig = 0;
} // BUG: Instruction pointer register will change to a bogus value when
returning.
int main(void)
{
Blowup();
// BUG: This loop will never be reached because Blowup() won't return
properly.
while(1) { wdt_reset(); }
}
4. The emitted assembly for Blowup function is problematic as follows, from
the LSS file:
volatile __int24 staticConfig = 0;
22a:22 96 adiwr28, 0x02; 2
22c:1d ae stdY+61, r1; 0x3d
22e:1e ae stdY+62, r1; 0x3e
230:1f ae stdY+63, r1; 0x3f
232:23 97 sbiwr28, 0x03; 3
AVR-GCC appears to hold the frame pointer in Y register pair: r28..r29. This
code corrupts that pointer, which is later adjusted again by the frame size and
stored in SPH/SPL, such that the subsequent ret instruction jumps to invalid
location.
The STD instruction is limited to a 6-bit immediate offset (Y+q syntax). The
staticConfig variable was stored in the frame normally beyond the reach of
this instruction, so AVR-GCC appears to try to use STD Y+q anyway by
temporary adding and then subtracting the appropriate offset to the frame
pointer. Except, that AVR-GCC appears to be incorrectly doing this - as we can
see the added value in ADIW of 0x02 is not the same as the subtracted value
in SBIW of 0x03. Examining the earlier assembly code seems to suggest that
the correct value for SBIW would be 0x02 also.
Because the SBIW instruction screwed up the Y register pair which is later
stored in SPH/SPL, the RET call jumps to bad memory. Also, I would imagine
subsequent variable accesses in the Blowup function to the stack would not
work properly.
I also suspect that reads from the staticConfig variable using LDD Y+q
instruction could have this same problem, but I did not test. LDD Y+q has
similar 6-bit limitation, so I suspect AVR-GCC would be using the same ADIW /
SBIW trick to work around that which failed here.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 --- Comment #1 from johnst...@inn-soft.com --- I don't really know GCC source code well enough to feel comfortable changing and testing this myself, but I suspect the problem lies with this code? gcc/config/avr/avr.c: avr_out_store_psi function: revision 209767: 3992 return avr_asm_len (adiw r28,%o0-61 CR_TAB 3993 std Y+61,%A1CR_TAB 3994 std Y+62,%B1CR_TAB 3995 std Y+63,%C1CR_TAB 3996 sbiw r28,%o0-60, op, plen, -5); Notice the top line has %o0-61 and bottom line has %o0-60, which must be some kind of offset. I suspect this code was copied and pasted from the out_movsi_mr_r function, while forgetting to update the last line here since it is 24-bit integer and not the 32-bit integer it was copied from. It appears that this code was introduced with the new __int24 support and nothing changed since then.
[Bug tree-optimization/60989] automatic increase of global array for vectorization doesn't work due to flag_section_anchors==0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60989 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org --- Ok fair enough.
[Bug c++/60992] New: [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992
Bug ID: 60992
Summary: [4.9/4.10 Regression] ICE in tsubst_copy, at
cp/pt.c:12637
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/14350545
Test:
/// --- cut ---
struct ScopeGuardGenerator { };
struct FF
{
template class F, class ... Ts
void
operator () (F ...)
{
const int n = sizeof ... (Ts);
void *mutexes[n];
auto _on_scope_exit_var_0 =
ScopeGuardGenerator () + [mutexes] { };
}
};
template class F
int operator+ (ScopeGuardGenerator, F) { return 1; }
struct D
{
template class T0, class T1, class T2, class ... T
void
operator () (T0, T1, const T2 t2, T ... t)
{
base (t2, t ...);
}
FF base;
};
D run_with_locks;
void Fn ()
{
run_with_locks ([] { }, 0, 0);
}
/// ---cut---
Using current trunk (r209848):
g++ -c -std=c++11 t2.ii
t2.ii: In instantiation of ‘FF::operator()(F, ...)::lambda() [with F = const
int; Ts = {}]’:
t2.ii:12:34: required from ‘struct FF::operator()(F, ...) [with F = const
int; Ts = {}]::lambda()’
t2.ii:12:30: required from ‘void FF::operator()(F, ...) [with F = const int;
Ts = {}]’
t2.ii:25:5: required from ‘void D::operator()(T0, T1, const T2, T ...)
[with T0 = Fn()::lambda(); T1 = int; T2 = int; T = {}]’
t2.ii:34:31: required from here
t2.ii:12:43: internal compiler error: in tsubst_copy, at cp/pt.c:12637
ScopeGuardGenerator () + [mutexes] { };
^
0x5d35cd tsubst_copy
../../gcc/cp/pt.c:12637
0x5af80b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:15150
0x5ba6f6 tsubst_expr
../../gcc/cp/pt.c:13979
0x5c4097 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11596
0x5c33f5 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:12045
0x5c2c4b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11561
0x5d55a0 tsubst_decl
../../gcc/cp/pt.c:11043
0x5c388f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11492
0x5bb12c tsubst_expr
../../gcc/cp/pt.c:13438
0x5bb249 tsubst_expr
../../gcc/cp/pt.c:13586
0x5b8399 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:19875
0x5f4147 instantiate_class_template_1
../../gcc/cp/pt.c:9334
0x5f4147 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:9402
0x6879f3 complete_type(tree_node*)
../../gcc/cp/typeck.c:134
0x5afa30 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:15247
0x5b19bb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:14362
0x5ba6f6 tsubst_expr
../../gcc/cp/pt.c:13979
0x5bd579 tsubst_expr
../../gcc/cp/pt.c:13489
0x5ba0a3 tsubst_expr
../../gcc/cp/pt.c:13381
0x5bb249 tsubst_expr
../../gcc/cp/pt.c:13586
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
The test compiles cleanly with Clang and gcc-4.8 (at least the version I have).
[Bug fortran/60993] New: Trouble initializing double precision variable using boz literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 Bug ID: 60993 Summary: Trouble initializing double precision variable using boz literals Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Created attachment 32701 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32701action=edit This code illustrates the problem above The attached file gets this error during the compile inf.f90:21:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:5446 dinfn = transfer(infn, dinfn) ! Comment this to see failure above. If you comment out the statement causing this problem you can see that a transfer with a parameter array to a double works, but the same fails when using an array literal. I am just interested in getting plus and minus infinity set in parameters or variables to use in my code. Their use really simplifies some code. I'd like them defined for single, double, and quad precisions.
[Bug fortran/60810] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 --- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Tue Apr 29 03:13:34 2014 New Revision: 209888 URL: http://gcc.gnu.org/viewcvs?rev=209888root=gccview=rev Log: 2014-04-28 Jerry DeLisle jvdeli...@gcc.gnu PR libfortran/60810 * gfortran.dg/arrayio_13.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_13.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/60810] [4.7/4.8/4.9/4.10 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Closing.
[Bug tree-optimization/60971] [4.9/4.10 Regression] Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971
--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
Isn't the real problem here that we emitted the tail call because we thought
the return type from foo was close enough to the return type from bar that
no coercion was needed?
In the .optimized dump we have:
bar ()
{
unsigned char _3;
_Bool _4;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
_3 = foo (); [tail call]
_4 = (_Bool) _3;
return _4;
;;succ: EXIT [100.0%]
}
Which is correct AFAICT.
Yet we turn that into:
jmp foo # 5 *sibcall_value [length = 5]
Which loses the conversion from unsigned char to _Bool which strips off the
bits outside _Bool.
We have the following code which is supposed to handle these kinds of cases,
but obviously isn't sufficient as deals strictly with RTL modes (and at the RTL
mode level, the return types are effectively equivalent)
/* Check if caller and callee disagree in promotion of function
return value. */
if (try_tail_call)
{
enum machine_mode caller_mode, caller_promoted_mode;
enum machine_mode callee_mode, callee_promoted_mode;
int caller_unsignedp, callee_unsignedp;
tree caller_res = DECL_RESULT (current_function_decl);
caller_unsignedp = TYPE_UNSIGNED (TREE_TYPE (caller_res));
caller_mode = DECL_MODE (caller_res);
callee_unsignedp = TYPE_UNSIGNED (TREE_TYPE (funtype));
callee_mode = TYPE_MODE (TREE_TYPE (funtype));
caller_promoted_mode
= promote_function_mode (TREE_TYPE (caller_res), caller_mode,
caller_unsignedp,
TREE_TYPE (current_function_decl), 1);
callee_promoted_mode
= promote_function_mode (TREE_TYPE (funtype), callee_mode,
callee_unsignedp,
funtype, 1);
if (caller_mode != VOIDmode
(caller_promoted_mode != callee_promoted_mode
|| ((caller_mode != caller_promoted_mode
|| callee_mode != callee_promoted_mode)
(caller_unsignedp != callee_unsignedp
|| GET_MODE_BITSIZE (caller_mode)
GET_MODE_BITSIZE (callee_mode)
try_tail_call = 0;
}
Not surprisingly, if I add -fno-optimize-sibling-calls the test passes.
