[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 --- Comment #8 from Nikolka 2012-09-10 06:26:02 UTC --- (In reply to comment #7) > (In reply to comment #3) > > g++ v4.7.2 20120908 (prerelease) compiles the original example successfully, > > but it fails to compile the following code: > > G++ is following the proposed resolution of DR 1402 here; A does not have > a move constructor A does have a move constructor, which is instantiated from A(A const volatile &&) = delete; See 12.8/3: A non-template constructor for class X is a move constructor if its first parameter is of type X&&, const X&&, volatile X&&, or const volatile X&&, and either there are no other parameters or else all other parameters have default arguments
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #15 from Benjamin Kosnik 2012-09-10 05:08:51 UTC --- In 4.7-branch
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #14 from Benjamin Kosnik 2012-09-10 05:08:15 UTC --- Author: bkoz Date: Mon Sep 10 05:08:07 2012 New Revision: 191125 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191125 Log: 2012-09-09 Thiago Macieira PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if we detect that another thread has had success. Don't compare_exchange from a finished state back to a waiting state. Comment. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/guard.cc --- Comment #15 from Benjamin Kosnik 2012-09-10 05:08:51 UTC --- In 4.7-branch
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #14 from Benjamin Kosnik 2012-09-10 05:08:15 UTC --- Author: bkoz Date: Mon Sep 10 05:08:07 2012 New Revision: 191125 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191125 Log: 2012-09-09 Thiago Macieira PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if we detect that another thread has had success. Don't compare_exchange from a finished state back to a waiting state. Comment. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/guard.cc
[Bug lto/51432] [4.6 regression] ICE in -flto -std=c++0x -g with cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51432 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #3 from Michael Hope 2012-09-10 03:59:49 UTC --- The fault also happens natively: cbuild@ursa2:~$ g++ -flto -std=c++0x -g -xc++ /dev/null -include functional In file included from /usr/include/c++/4.6/functional:59:0, from :0: /usr/include/c++/4.6/bits/functional_hash.h: In instantiation of 'std::size_t std::hash<_Tp>::operator()(_Tp) const [with _Tp = long double, std::size_t = unsigned int]': /usr/include/c++/4.6/functional:2267:1: instantiated from here /usr/include/c++/4.6/bits/functional_hash.h:184:5: internal compiler error: in write_builtin_type, at cp/mangle.c:2168 cbuild@ursa2:~$ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 This isn't FSF 4.6.3 but is pretty close.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 --- Comment #7 from Jason Merrill 2012-09-10 02:09:26 UTC --- (In reply to comment #3) > g++ v4.7.2 20120908 (prerelease) compiles the original example successfully, > but it fails to compile the following code: G++ is following the proposed resolution of DR 1402 here; A does not have a move constructor and it is not trivially copyable, so the B move constructor is not implicitly declared. This seems like a flaw in the 1402 drafting; the template constructor should count.
[Bug web/54539] pdf docs on web site are bzipped: unusable on Apple Ipad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54539 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andrew Pinski 2012-09-09 23:25:39 UTC --- Complain to Apple then as they work for me with Adobe reader and many other pdf readers.
[Bug web/54539] New: pdf docs on web site are bzipped: unusable on Apple Ipad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54539 Bug #: 54539 Summary: pdf docs on web site are bzipped: unusable on Apple Ipad Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: tom.brow...@gmail.com pdf docs (gcc and libstdc++ manuals) are bzipped (saving little space) which cannot be downloaded on Apple Ipad 3.
[Bug libstdc++/43852] Embedded systems friendly libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #21 from Jonathan Wakely 2012-09-09 23:09:53 UTC --- Done for 4.8.0
[Bug libstdc++/43852] Embedded systems friendly libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 --- Comment #20 from Jonathan Wakely 2012-09-09 23:08:54 UTC --- Author: redi Date: Sun Sep 9 23:08:48 2012 New Revision: 191121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191121 Log: 2012-09-10 Sebastian Huber Jonathan Wakely PR libstdc++/43852 * acinclude.m4 (GLIBCXX_ENABLE_VERBOSE): Define. * configure.ac (GLIBCXX_ENABLE_VERBOSE): Use it. * config.h.in: Regenerate. * configure: Likewise. * libsupc++/eh_term_handler.cc (_GLIBCXX_VERBOSE): Check new macro. * libsupc++/pure.cc (_GLIBCXX_VERBOSE): Likewise. * doc/xml/manual/configure.xml (--disable-libstdcxx-verbose): Document. * doc/html/manual/configure.html: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/html/manual/configure.html trunk/libstdc++-v3/doc/xml/manual/configure.xml trunk/libstdc++-v3/libsupc++/eh_term_handler.cc trunk/libstdc++-v3/libsupc++/pure.cc
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW CC||jason at gcc dot gnu.org --- Comment #6 from Jonathan Wakely 2012-09-09 22:59:01 UTC --- (In reply to comment #5) > These examples aren't similar. You're right I reduced it too far, sorry. I'll confirm this then and CC Jason to look at it.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 --- Comment #5 from Nikolka 2012-09-09 22:42:03 UTC --- (In reply to comment #4) These examples aren't similar. An implicitly defined move constructor performs direct-initialization of non-static data members with the corresponding members of the argument, which is interpreted as xvalue (12.8/15). In every such a direct-initialization all constructors are considered (13.3.1.3), including constructor templates. Template argument for the parameter U can be deduced as int, and the produced specialization of the constructor template will have better match than both copy and move constructors. Similarly for assignment operators. > struct A cannot be moved because its move operations are deleted This is not so in my example, and g++ correctly handles the following case: template struct A { A() {} A(A const volatile &&) = delete; A &operator =(A const volatile &&) = delete; template A(A &&) {} template A &operator =(A &&) { return *this; } }; int main() { A a = A(); // OK a = A(); // OK }
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 --- Comment #4 from Jonathan Wakely 2012-09-09 21:36:40 UTC --- The example can be simplified to struct A { A() {} A(A &&) = delete; A &operator =(A &&) = delete; }; struct B { A a; B() = default; }; int main() { B b = B(); b = B(); } I think this is ill-formed, so G++ is right to reject it. struct A cannot be moved because its move operations are deleted, and cannot be copied because the implicit-declared copy operations are defined as deleted, see [class.copy]/7. Therefore struct B cannot be moved or copied either.
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||WORKSFORME --- Comment #5 from Steven Bosscher 2012-09-09 21:27:30 UTC --- > gcc should make the transformation when it improves the code (like > all other transformations). And how is gcc supposed to tell when this is an improvement? Your "like all other transformations" makes no sense, this is not something simple like constant propagation or redundancy elimination that's almost always a win. > gcc often transforms a switch to a dispatch table, Yes, an existing switch, that someone wrote or generated deliberately as a switch. > gcc should allow the programmer to write the code in the cleanest way, > and transform it to the most performing way. Kicking in open doors doesn't help. A compiler is not an omniscient, omnipotent translator. If the compiler can't tell whether the transformation is profitable, it has to use some heuristics to make a best guess. In this case, the trade-off is expanding a compact indirect call to a large body of a switch statement. This might increase the number of branches (e.g. if the switch is lowered as a decision tree), it could ruin icache, and it may go against the intent of the programmer. There are no immediately obvious benefits visible to the compiler. With -fprofile-use GCC already performs inlining of the most frequently called callee of an indirect function calls table. It's the only situation where GCC can be sure that the transformation is profitable. If you want a switch, write a switch.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 --- Comment #3 from Nikolka 2012-09-09 20:55:38 UTC --- g++ v4.7.2 20120908 (prerelease) compiles the original example successfully, but it fails to compile the following code: template struct A { A() {} A(A const volatile &&) = delete; A &operator =(A const volatile &&) = delete; template A(A &&) {} template A &operator =(A &&) { return *this; } }; struct B { A a; B() = default; }; int main() { B b = B(); b = B(); } Target: i686-pc-linux-gnu Configured with: ../configure --prefix=../target --enable-languages=c,c++ Thread model: posix gcc version 4.7.2 20120908 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' ../target/libexec/gcc/i686-pc-linux-gnu/4.7.2/cc1plus -quiet -v -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=pentiumpro -auxbase test -std=c++11 -version -o /tmp/cc0973J0.s GNU C++ (GCC) version 4.7.2 20120908 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.7.2 20120908 (prerelease), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.8.2 test.cpp: In function ‘int main()’: test.cpp:23:17: error: use of deleted function ‘B::B(const B&)’ test.cpp:15:12: note: ‘B::B(const B&)’ is implicitly deleted because the default definition would be ill-formed: test.cpp:15:12: error: use of deleted function ‘constexpr A::A(const A&)’ test.cpp:2:16: note: ‘constexpr A::A(const A&)’ is implicitly declared as deleted because ‘A’ declares a move constructor or move assignment operator test.cpp:24:15: error: use of deleted function ‘B& B::operator=(const B&)’ test.cpp:15:12: note: ‘B& B::operator=(const B&)’ is implicitly deleted because the default definition would be ill-formed: test.cpp:15:12: error: use of deleted function ‘A& A::operator=(const A&)’ test.cpp:2:16: note: ‘A& A::operator=(const A&)’ is implicitly declared as deleted because ‘A’ declares a move constructor or move assignment operator
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #63 from Jonathan Wakely 2012-09-09 20:45:11 UTC --- (In reply to comment #55) > AFAICT nobody has been asking to cross post to libstdc++. Also see comment 40, before the first patch.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #62 from Jonathan Wakely 2012-09-09 19:46:45 UTC --- Author: redi Date: Sun Sep 9 19:46:41 2012 New Revision: 191119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191119 Log: PR bootstrap/54419 * acinclude.m4 (GLIBCXX_CHECK_X86_RDRAND): Remove stray character. * configure: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug c++/54538] New: Getting assembler messages when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54538 Bug #: 54538 Summary: Getting assembler messages when compiling Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: leo...@volnitsky.com Created attachment 28157 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28157 scc.ii I am getting "Assembler Messages" below from gcc-4.8 when compiling my code. scc.ii file is attached (original code -- https://github.com/lvv/scc ). I can successfully compile if I will use gcc-3.7.1. Error Messages: --- {standard input}: Assembler messages: {standard input}:12769: Error: symbol `_ZNK3sto11chain_rangeIT_E12default_predMUlRKiE_clES4_' is already defined {standard input}:17883: Error: symbol `_ZSt4moveIRN3sto11chain_rangeIT_E12default_predMUlRKiE_EEONSt16remove_referenceIS2_E4typeEOS2_' is already defined {standard input}:17903: Error: symbol `_ZNSt8functionIFbRKiEEC2IN3sto11chain_rangeIT_E12default_predMUlS1_E_EvEET_' is already defined {standard input}:23564: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE21_M_not_empty_functionIS7_EEbRKT_' is already defined {standard input}:23583: Error: symbol `_ZNSt17_Function_handlerIFbRKiEN3sto11chain_rangeIT_E12default_predMUlS1_E_EE9_M_invokeERKSt9_Any_dataS1_' is already defined {standard input}:23617: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE10_M_managerERSt9_Any_dataRKS9_St18_Manager_operation' is already defined {standard input}:23722: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE15_M_init_functorERSt9_Any_dataOS7_' is already defined {standard input}:28014: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE14_M_get_pointerERKSt9_Any_data' is already defined {standard input}:28040: Error: symbol `_ZNSt9_Any_data9_M_accessIPN3sto11chain_rangeIT_E12default_predMUlRKiE_EEERS3_v' is already defined {standard input}:28062: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE8_M_cloneERSt9_Any_dataRKS9_St17integral_constantIbLb0EE' is already defined {standard input}:28096: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE10_M_destroyERSt9_Any_dataSt17integral_constantIbLb0EE' is already defined {standard input}:28121: Error: symbol `_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE15_M_init_functorERSt9_Any_dataOS7_St17integral_constantIbLb0EE' is already defined {standard input}:31822: Error: symbol `_ZNKSt9_Any_data9_M_accessIPN3sto11chain_rangeIT_E12default_predMUlRKiE_EEERKS3_v' is already defined -- Compiled with: g++ -std=gnu++11 -Wall -pipe -Wno-sign-compare -I /home/lvv/p/ -include debug.h -Wno-unused-function -I /home/lvv/p/scc -I /home/lvv/p -include /home/lvv/p/scc/.scc.h /home/lvv/p/scc/scc.cc -o /tmp/lvv-scc GCC version: gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,go,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.0_pre' Thread model: posix gcc version 4.8.0-pre 20120820 (experimental) commit 2bf99680c2012de150798c933642aa4c82a85410 (Gentoo 4.8.0_pre)
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Jonathan Wakely 2012-09-09 18:44:59 UTC --- fixed
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 --- Comment #15 from Jonathan Wakely 2012-09-09 18:40:50 UTC --- Author: redi Date: Sun Sep 9 18:40:46 2012 New Revision: 191117 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191117 Log: PR libstdc++/54388 * include/std/array (array::at() const): Ensure lvalue result. * testsuite/23_containers/array/element_access/54388.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/array/element_access/54388.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/std/array
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #61 from Dominique d'Humieres 2012-09-09 18:17:09 UTC --- > patch committed Thanks.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #7 from Jonathan Wakely 2012-09-09 18:18:32 UTC --- No, it should be consistent with how it's handled everywhere else.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #6 from rbmj at verizon dot net 2012-09-09 18:08:11 UTC --- Making local changes to bring stdint.h into compliance works for me as well. (In reply to comment #5) > (In reply to comment #4) > > Maybe it would be nice to use #error in header file to inform the user that > > this feature is not supported for target system (nicer than to get linker > > error > > later) > > You won't get a linker error, if the macro is not defined then the types in > are not declared, so code using them won't compile. However, you will get weird "std::random_device" not declared errors, which will seem strange to any end user. > Using #error would prevent #include which I don't think is a good > idea. There's no harm including the header as long as you don't try to use > types which require a working Agreed. But could we use #warning to tell the user what's happening (if portability is an issue we can check for __GNUC__) without going through the source? > The fix is to simply make random.cc check the macro. This is what we already > do > in future.cc and thread.cc and mutex.cc and other files too. Also true.
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 --- Comment #13 from Jonathan Wakely 2012-09-09 17:56:15 UTC --- (In reply to comment #10) > Can the compiler warn about the original (buggy) code? It already does: c.cc: In function ‘A& get(int)’: c.cc:3:43: error: invalid initialization of non-const reference of type ‘A&’ from an rvalue of type ‘A’ A& get(int i) { return i == 0 ? a : throw 1; } ^ But warnings are suppressed in system headers. --- Comment #14 from Jonathan Wakely 2012-09-09 17:56:56 UTC --- Author: redi Date: Sun Sep 9 17:56:51 2012 New Revision: 191114 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191114 Log: PR libstdc++/54388 * include/std/array (array::at() const): Ensure lvalue result. * testsuite/23_containers/array/element_access/54388.cc: New. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/array/element_access/54388.cc - copied, changed from r191113, trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/array trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 --- Comment #13 from Jonathan Wakely 2012-09-09 17:56:15 UTC --- (In reply to comment #10) > Can the compiler warn about the original (buggy) code? It already does: c.cc: In function ‘A& get(int)’: c.cc:3:43: error: invalid initialization of non-const reference of type ‘A&’ from an rvalue of type ‘A’ A& get(int i) { return i == 0 ? a : throw 1; } ^ But warnings are suppressed in system headers.
[Bug c++/54537] undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-09 AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.6.3, 4.8.0
[Bug c++/54537] New: undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 Bug #: 54537 Summary: undiagnosed using-declaration conflicting with used function Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: fab...@gcc.gnu.org Noticed while working on DR39, the below is wrongly accepted. A diagnostic is issued if the function f is not used. namespace a { void f(int); } namespace b { void f(int); void g() { f (3); } using a::f; // { dg-error "already declared" } } I have a patch for it.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #60 from Jonathan Wakely 2012-09-09 17:30:30 UTC --- patch committed
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #59 from Jonathan Wakely 2012-09-09 17:20:47 UTC --- Author: redi Date: Sun Sep 9 17:20:42 2012 New Revision: 19 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=19 Log: 2012-09-09 Ulrich Drepper Dominique d'Humieres Jack Howarth PR bootstrap/54419 * acinclude.m4: Define GLIBCXX_CHECK_X86_RDRAND. * configure.ac: Use GLIBCXX_CHECK_X86_RDRAND to test for rdrand support in assembler. * src/c++11/random.cc (__x86_rdrand): Depend on _GLIBCXX_X86_RDRAND. (random_device::_M_init): Likewise. (random_device::_M_getval): Likewise. * configure: Regenerated. * config.h.in: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/src/c++11/random.cc
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #5 from Jonathan Wakely 2012-09-09 17:19:44 UTC --- (In reply to comment #4) > Maybe it would be nice to use #error in header file to inform the user that > this feature is not supported for target system (nicer than to get linker > error > later) You won't get a linker error, if the macro is not defined then the types in are not declared, so code using them won't compile. Using #error would prevent #include which I don't think is a good idea. There's no harm including the header as long as you don't try to use types which require a working The fix is to simply make random.cc check the macro. This is what we already do in future.cc and thread.cc and mutex.cc and other files too.
[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021 --- Comment #9 from Jason Merrill 2012-09-09 16:48:46 UTC --- (In reply to comment #5) > // This causes "error: the value of 'x' is not usable in a constant > expression" > constexpr bool c = __builtin_constant_p(x); > } This is also fixed by my patch.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #4 from Andris Pavenis 2012-09-09 16:47:44 UTC --- My test was done with DJGPP development version (2.04) only. It has stdint.h, but it was recognized by configure as unusable due to bug unrelated to GCC itself. After fixing this problem locally libstdc++-v3 builds OK for DJGPP v2.04 (only tested cross-native build from Linux) Stable version DJGPP v2.03 does not have stdint.h As the result I agree with the suggestion in comment 3 to completely disable random.cc when _GLIBCXX_USE_C99_STDINT_TR1 is not defined Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later)
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #58 from Jonathan Wakely 2012-09-09 16:21:25 UTC --- (In reply to comment #56) > I suppose that the lack of responsiveness may be ultimately due to the fact > that the issue only shows up on some specific systems (that is, those using > old > assemblers) which normally the maintainers (in general, not just the library > ones) working on mainline GCC don't develop on The fact the build was broken on the compile farm machines would normally be an issue for me, but as I was on holiday I wasn't building gcc. As soon as I tried to build on the compile farm I found the PR and reviewed the patch. Again, if it had been sent to the right list I could have done that sooner, instead of waiting until the bug affected me directly.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #57 from Jonathan Wakely 2012-09-09 16:18:12 UTC --- (In reply to comment #55) > (1) A new patch has been posted at > http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html to fix a typo in my > email address. But not to a list I actually read. > (2) Jack Howarth does not seem to be around. So if someone with write access > care about ASAP, he(r)? may commit the last version. I'll do it today. > AFAICT nobody has been asking to cross post to libstdc++. See http://gcc.gnu.org/contribute.html#patches and http://gcc.gnu.org/lists.html "Patches to libstdc++-v3 should be sent to both this list and gcc-patches." That is the standard policy, that's true whether or not anyone noticed the policy wasn't followed or pointed it out. Anyway, I'm asking now. Please follow the policy in future if you want me to review libstdc++ patches. > (4) Managing libstdc++ on a specific mailing list made sense when G++ was an > optional component of GCC. Now that C++, hence libstdc++, is mandatory, I > think > this policy should be revised: > - the final patch should be posted and approved on gcc-patc...@gcc.gnu.org; No, it should go to both. I don't want to subscribe to gcc-patches to review just the libstdc++ patches, and I doubt everyone subscribed to g...@gcc.gnu.org wants to read discussion of e.g. the C++11 standard library components (which aren't used by the rest of GCC.) If patches are sent to both lists I can reply-to-all and the approval and review will be sent to both lists. I see no reason to change that policy. In any case, changing policies should be discussed on the gcc list, not in bugzilla. > - the libstdc++ maintainers should be more careful: four bootstrap failures > caused by a single commit is way to much; > - the libstdc++ maintainers should be more responsive: more than ten days to > fix a bootstrap failure on primary platforms is way too long. Myself and Paolo were both travelling for the past week, so we were less responsive than normal. If the patch had been posted to the right list I would have reviewed the patch while on holiday, but I didn't even realise there was a patch to fix it because it wasn't sent to the list I read (I was surprised when I got back from holiday to find the change hadn't been reverted after the 48 hour countdown was started.)
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #56 from Paolo Carlini 2012-09-09 16:14:41 UTC --- I suppose that the lack of responsiveness may be ultimately due to the fact that the issue only shows up on some specific systems (that is, those using old assemblers) which normally the maintainers (in general, not just the library ones) working on mainline GCC don't develop on and don't assume are the reference systems on which the next release series will be eventually primarily installed. Indeed, if you look at gcc-patches it's pretty obvious that the development of GCC mainline proceeded quite normally, and, at this stage at least, this is what *really* counts.
[Bug fortran/54522] Using "g77 -O -fno-automatic", reassignment of a variable in an if statement in a function triggers a compiler bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54522 --- Comment #3 from Dominique d'Humieres 2012-09-09 15:27:29 UTC --- The test case with -O -fno-automatic compiles on powerpc-apple-darwin9 with gcc 3.4.3.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #55 from Dominique d'Humieres 2012-09-09 15:21:45 UTC --- (In reply to comments #53 and #54) > Please post the patch to the right list and I'll approve it, all libstdc++ > patches need to go to the libstdc++ list. > > I've tested the patch myself now, it's ok, please commit it asap (but in > future > remember to send patches to the libstdc++ list as well as gcc-patches, I could > have approved it sooner had I seen it) I'ld to make a few comments: (1) A new patch has been posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html to fix a typo in my email address. (2) Jack Howarth does not seem to be around. So if someone with write access care about ASAP, he(r)? may commit the last version. (3) Jack has posted five revisions of the patch: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00409.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00416.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00421.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00465.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html following the request made at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00411.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00417.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00418.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00432.html followed by a last post http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00499.html AFAICT nobody has been asking to cross post to libstdc++. (4) Managing libstdc++ on a specific mailing list made sense when G++ was an optional component of GCC. Now that C++, hence libstdc++, is mandatory, I think this policy should be revised: - the final patch should be posted and approved on gcc-patc...@gcc.gnu.org; - the libstdc++ maintainers should be more careful: four bootstrap failures caused by a single commit is way to much; - the libstdc++ maintainers should be more responsive: more than ten days to fix a bootstrap failure on primary platforms is way too long.
[Bug target/54536] New: [avr]: incorrect crt with -mmcu=at90usb1287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54536 Bug #: 54536 Summary: [avr]: incorrect crt with -mmcu=at90usb1287 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.schaenz...@nurfuerspam.de The avr-gcc driver is linking against crtusb1286.o when using the mcu option -mmcu=at90usb1287. It should use crtusb1287.o instead. Since crtusb1286.o and crtusb1287.o are identical this is ok for the default avr-libc multilib setup but causes problems with non-standard build systems (e.g. device specific builds).
[Bug fortran/54522] Using "g77 -O -fno-automatic", reassignment of a variable in an if statement in a function triggers a compiler bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54522 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2012-09-09 14:48:16 UTC --- (In reply to comment #1) > g77 is no longer supported. gfortran, which is g77's successor, does not seem to have any trouble with your test case (I tried versions 4.3, 4.6, 4.7 and trunk). Please consider upgrading to gfortran.
[Bug c++/54535] New: gcc fails to warn when functions are inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54535 Bug #: 54535 Summary: gcc fails to warn when functions are inlined Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@doublewise.net #include namespace { static void f(bool condition) { volatile int const x = (__builtin_constant_p(condition) ? (1 / (condition)) : 0); \ } } int main() { f(false); } I compile this with -Werror=div-by-zero, and I do not get any warnings while compiling. Instead, I get "Floating point exception (core dumped)" when I attempt to run it. The same sort of thing happens with other situations that should be warned about, such as indexing an array with a negative number. I do get a warning if I manually inline the call to f or make it a macro. gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
[Bug pch/39618] trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Jonathan Wakely 2012-09-09 12:02:53 UTC --- Thanks, closing then
[Bug c++/54532] [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54532 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-09 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely 2012-09-09 12:01:29 UTC --- also ICEs on trunk
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-09 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely 2012-09-09 11:50:18 UTC --- (In reply to comment #0) > Commenting out '#ifdef _GLIBCXX_USE_C99_STDINT_TR1' fixed build problem, but > I'm not sure that it is correct solution. It's not. (In reply to comment #1) > etc. Those are the only uses of it in code that I can find. It's used in many more headers. > It seems like it > isn't exactly the best name for the define (it no longer just applies to TR1), > but it doesn't do too much. I can't think of a case where this would not be > desired behavior (I don't remember, but I *think* that the C++ standard says > that those typenames should be in the standard namespace). But the C standard requires and if the OS doesn't provide that we can't provide a useful . > Anyway, it doesn't appear like removing that code will have any adverse > effects. It would completely break libstdc++ on platforms without , such as djgpp The fix is simply to check for the macro in random.cc index 50b5359..1d0723d 100644 --- a/libstdc++-v3/src/c++11/random.cc +++ b/libstdc++-v3/src/c++11/random.cc @@ -24,6 +24,8 @@ #include +#ifdef _GLIBCXX_USE_C99_STDINT_TR1 + #if defined __i386__ || defined __x86_64__ # include #endif @@ -142,5 +144,5 @@ namespace std _GLIBCXX_VISIBILITY(default) 0xUL, 7, 0x9d2c5680UL, 15, 0xefc6UL, 18, 1812433253UL>; - } +#endif
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 Andreas Schwab changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #8 from Andreas Schwab 2012-09-09 11:44:55 UTC --- *** Bug 54530 has been marked as a duplicate of this bug. ***
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Paolo Carlini changed: What|Removed |Added CC||drepper.fsp at gmail dot ||com --- Comment #2 from Paolo Carlini 2012-09-09 11:44:45 UTC --- If it's not defined, it means that the configure time tests fails because the target doesn't support the feature. In general - even for stdint which is supported by most targets now - we should simply make sure that the build works in both cases, simply the features may end up not being available. Adding Ulrich in CC, something needs tweaking in his recent work.
[Bug libstdc++/54530] [4.8 regression] error: std::piecewise_construct causes a section type conflict with std::piecewise_construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54530 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|aaw at google dot com, | |fdumont at gcc dot gnu.org | Resolution||DUPLICATE --- Comment #2 from Andreas Schwab 2012-09-09 11:44:55 UTC --- Apparently a dup. *** This bug has been marked as a duplicate of bug 53475 ***
[Bug target/29845] sh floating point emulation is inefficient
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #8 from Oleg Endo 2012-09-09 11:22:33 UTC --- Just for the record, a rather recent discussion on the issue: Original thread start: http://gcc.gnu.org/ml/gcc/2010-06/msg00388.html Continuation: http://gcc.gnu.org/ml/gcc/2010-07/msg00250.html Continuation: http://gcc.gnu.org/ml/gcc/2010-08/msg00044.html Aggregated version: http://www.mentby.com/Group/gcc-discuss/sh-optimized-software-floating-point-routines.html
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505 --- Comment #4 from Avi Kivity 2012-09-09 11:12:53 UTC --- (In reply to comment #2) > I don't think this transformation would always be an improvement. gcc should make the transformation when it improves the code (like all other transformations). > Had a > developer wanted to use a switch, I'd think he/she would have used one. A > dispatch table is much more code-size efficient compared to a switch. gcc often transforms a switch to a dispatch table, with the difference that the function call convention is not used. Instead, register values are maintained across the call, and instead of call/ret, jmp/jmp (on x86) are used. gcc should allow the programmer to write the code in the cleanest way, and transform it to the most performing way. In the same way that gcc converts some multiplies to a shift, it should convert some indirect function calls to a non-function dispatch table. It's inlining but on a larger scale.
[Bug target/54531] vpermilpd(x, 2 or 10) is a move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54531 --- Comment #1 from Marc Glisse 2012-09-09 09:30:57 UTC --- As a side note, is there a reason to prefer vpermpd to vpermilpd when both are available (apart from the fact that they are written in that order in the .md file)? I would expect that by default we take the intra-lane version, which in theory could be cheaper on some machines. I guess in practice they are equivalent and it doesn't matter...
[Bug pch/39618] trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618 kettenis at gnu dot org changed: What|Removed |Added CC||kettenis at gnu dot org --- Comment #6 from kettenis at gnu dot org 2012-09-09 08:44:02 UTC --- This is fixed by the following commit. Turns out it is possible to use a carefully chosen address to get PCH working reliably, so I did go for that approach since it has a chance to work if GCC is compiled as a position independent executable as well. 2012-09-02 Mark Kettenis * config.gcc (x86_64-*-openbsd*): New target. * config.host (*-*-openbsd*): New target. * config/openbsd.h (TARGET_C99_FUNCTIONS): Define. * config/i386/openbsdelf.h: Remove some superfluous defines and group things together in a more logical fashion. (DBX_REGISTER_NUMBER): Provide a definition that works on both 32-bit and 64-bit targets. (WCHAR_TYPE_SIZE): Hardcode as 32. (NO_DOLLAR_IN_LABEL): Remove undef. (TARGET_DEFAULT): Remove. (SET_ASM_OP): Remove. (DEFAULT_PCC_STRUCT_RETURN): Undef first to prevent warning. (ASM_OUTPUT_MAX_SKIP_ALIGN): Synch with x86-64.h (DWARF2_UNWIND_INFO): Remove define. (HAVE_ENABLE_EXECUTE_STACK): Define. * config/host-openbsd.c: New file. * config/t-openbsd (USER_H): Add EXTRA_HEADERS. * config/x-openbsd: New file.
[Bug debug/54534] New: [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 Bug #: 54534 Summary: [4.7 Regression] Missing location for unused variable Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-unknown-linux-gnu static int i; gcc -c -Wall -g 13.c:1:12: warning: ‘i’ defined but not used [-Wunused-variable] PASS: gcc (GCC) 4.5.4 PASS: gcc (GCC) 4.6.4 20120909 (prerelease) PASS: gcc (GCC) 4.8.0 20120909 (experimental) <1><2d>: Abbrev Number: 2 (DW_TAG_variable) <2e> DW_AT_name: i <30> DW_AT_decl_file : 1 <31> DW_AT_decl_line : 1 <32> DW_AT_type: <0x40> <36> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) (gdb) p i $1 = 0 FAIL: gcc (GCC) 4.7.2 20120909 (prerelease) <1><1d>: Abbrev Number: 2 (DW_TAG_variable) <1e> DW_AT_name: i <20> DW_AT_decl_file : 1 <21> DW_AT_decl_line : 1 <22> DW_AT_type: <0x26> (gdb) p i No symbol "i" in current context. Regression: 2012-09-07 -> 2012-09-08 It breaks GDB several testfiles such as: gdb.base/memattr.exp
[Bug c++/54527] wcout breaks on win32 console
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54527 vurentjie changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from vurentjie 2012-09-09 07:25:24 UTC --- nevermind
[Bug c++/54527] wcout breaks on win32 console
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54527 vurentjie changed: What|Removed |Added Severity|blocker |enhancement
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 --- Comment #3 from Andrew Pinski 2012-09-09 07:17:00 UTC --- (In reply to comment #2) > Looks like powerpc has the same issue: > http://sourceware.org/ml/gdb/2009-01/msg00161.html Which has a patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01213.html Though I don't know what happened to that. Though it does look there is a target specific part to it.
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 --- Comment #2 from Andrew Pinski 2012-09-09 07:12:07 UTC --- Looks like powerpc has the same issue: http://sourceware.org/ml/gdb/2009-01/msg00161.html
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 --- Comment #1 from Andrew Pinski 2012-09-09 07:01:52 UTC --- I have seen a bug about this before but I cannot find it. It only happen on x86_64 as al tells the function if it uses floating point arguments or not. It might be a bug in gdb in figuring out the prologue of the function too.