[Bug lto/53895] [4.7.2/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53895 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-09 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-07-09 06:28:27 UTC --- Does it work with BFD linker?
[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53887 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|steven at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org |
[Bug c/53896] New: nonreturning function suggested as 'pure' candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53896
Bug #: 53896
Summary: nonreturning function suggested as 'pure' candidate
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: egg...@gnu.org
I ran into this problem when building a test version of Emacs
with GCC 4.7.1 (x86-64). I simplified it to a small test case.
Take this program:
void lose (const char *msg) __attribute__((__noreturn__));
const char *
get_prefix (int running_suid)
{
if (!running_suid)
lose (Not using a shared game directory, and no prefix given.);
return foo;
}
Compile it with:
gcc -c -O2 -Wsuggest-attribute=pure t.c
The output will be:
t.c:4:1: warning: function might be candidate for attribute 'pure' if it is
known to return normally [-Wsuggest-attribute=pure]
But the get_prefix function is obviously not a candidate for attribute
'pure', since it might not return.
This bug may be related to Bug#50021 (currently apparently fixed in
GCC 4.7.0) and to Bug#51971 (documentation unclear for 'pure').
[Bug c/53897] New: one line of include stuck the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53897 Bug #: 53897 Summary: one line of include stuck the compiler Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: wuxian...@gmail.com System: Windows 7 Ultimate Version: MinGW GCC 4.7.0 Code: #include con Symptom: Just one line of the above code in a single file will stuck the compiler. This effect is also found on Windows Server 2003 SP2 with MinGW GCC 4.4.0.
[Bug c/53897] one line of include stuck the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53897 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-09 08:16:36 UTC --- Yes because con is the console file under Windows (DOS). GCC is reading from the include file from the console at that point.
[Bug c/53897] one line of include stuck the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53897 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-09 08:17:47 UTC --- This is like including /dev/console under UNIX (GNU/Linux).
[Bug lto/53895] [4.7/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53895 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.1 Target Milestone|--- |4.7.2 Summary|[4.7.2/4.8 Regression][lto] |[4.7/4.8 Regression][lto] |symbol |symbol |'std::__once_callable' used |'std::__once_callable' used |as both __thread and|as both __thread and |non-__thread|non-__thread Known to fail||4.7.2
[Bug c/53890] bogus array bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53890 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 08:39:18 UTC --- I'm pretty sure we have duplicates for this case.
[Bug middle-end/53884] [4.7/4.8 Regression] ICE: in function_and_variable_visibility, at ipa.c:818 with -flto -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53884 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/53875] calls to const functions are eliminated at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53875 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-09 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 08:42:26 UTC --- Confirmed. We generally do very many small optimizations at -O0 that would surprise users. we probably should not.
[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org 2012-07-09 08:43:33 UTC --- this is now fixed on trunk by: http://gcc.gnu.org/viewcvs?view=revisionrevision=188793 We will have to consider whether it is a reasonable back-port (at least to 4.7). Although it touches objc and doc, it is localized in effect to Darwin.
[Bug libfortran/49970] make prefix=... install doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970 --- Comment #12 from jimis jimis at gmx dot net 2012-07-09 09:52:52 UTC --- (In reply to comment #10) bug-libt...@gnu.org FWIW I had sent this but got no reply: http://lists.gnu.org/archive/html/bug-libtool/2011-08/msg3.html Maybe we should open this or the other GCC PR so we can keep track of this unwanted behaviour?
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 jimis jimis at gmx dot net changed: What|Removed |Added CC||abel at gcc dot gnu.org --- Comment #25 from jimis jimis at gmx dot net 2012-07-09 10:03:37 UTC --- I attach a patch almost similar to yours that I think handles the max negative issue (but presumes 2's complement representation, and that HOST_WIDE_INT is always larger or equal type than long). Passed testing on i386, bootstrapped fine on x86_64 multilib, I'd appreciate testing on 32-bit multilib platform.
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #26 from jimis jimis at gmx dot net 2012-07-09 10:06:53 UTC --- Created attachment 27765 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27765 fprint_w reinstated
[Bug bootstrap/53898] New: [4.8 regression] bootstrap failure: graphite-optimize-isl.c: ISO C forbids an empty translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53898 Bug #: 53898 Summary: [4.8 regression] bootstrap failure: graphite-optimize-isl.c: ISO C forbids an empty translation unit Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.8-20120708 on x86_64-linux with --disable-build-poststage1-with-cxx and no cloog installed fails for me with: /mnt/scratch/objdir48/./prev-gcc/xgcc -B/mnt/scratch/objdir48/./prev-gcc/ -B/mnt/scratch/install48/x86_64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/x86_64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/x86_64-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install48/x86_64-unknown-linux-gnu/include -isystem /mnt/scratch/install48/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.8-20120708/gcc -I/mnt/scratch/gcc-4.8-20120708/gcc/. -I/mnt/scratch/gcc-4.8-20120708/gcc/../include -I/mnt/scratch/gcc-4.8-20120708/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-x86_64/gmp-5.0.5/include -I/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.1/include -I/home/mikpe/pkgs/linux-x86_64/mpc-0.9/include -I/mnt/scratch/gcc-4.8-20120708/gcc/../libdecnumber -I/mnt/scratch/gcc-4.8-20120708/gcc/../libdecnumber/bid -I../libdecnumber /mnt/scratch/gcc-4.8-20120708/gcc/graphite-optimize-isl.c -o graphite-optimize-isl.o /mnt/scratch/gcc-4.8-20120708/gcc/graphite-optimize-isl.c:471:0: error: ISO C forbids an empty translation unit [-Werror=pedantic] #endif ^ cc1: all warnings being treated as errors make[3]: *** [graphite-optimize-isl.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir48/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 This is a regression from 4.8-20120701 which bootstrapped fine. Apart from the standard preamble all of graphite-optimize-isl.c is inside an #ifdef HAVE_cloog. I would suggest either not compiling this file at all when !HAVE_cloog, or to drop -Werror when compiling it. For now I'm resuming my build with an #else int this_is_silly; inserted before the trailing #endif.
[Bug c/53871] Please warn about endless loops if they are obvious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 --- Comment #2 from Tim Ruehsen tim.ruehsen at gmx dot de 2012-07-09 11:50:19 UTC --- (In reply to comment #1) (In reply to comment #0) Obvious endless loops could be reported, e.g. if the loop condition doesn't change and the loop can't be left otherwise. There has been discussions about this since more than ten years ago and nothing has happened: http://gcc.gnu.org/ml/gcc/1999-08n/msg00720.html More than 12 years of discussions... sigh. My understanding is that the probability of an existing GCC dev implementing this is very close to zero for various reasons: People are busy with other things, not trivial to implement for non-trivial code, risk of being too noisy, and there are other tools better at this job like splint and Clang's static analyzer. Neither splint nor clang understands gcc/ibm/intel nested functions, which I use a lot (yes, I know of the stack execution issue). Clang community so far refused to implement it, they propably never will. At least they have 'blocks' which might be a good alternative to nested functions. Splint isn't developed since 2007. Many years ago, I put nested functions on splint's wishlist - same answer as yours: go and implement it yourself !. (If I had time to to that, I wouldn't have put it on the wishlist but created a patch.) Maybe it's time for a gcc static analyzer...
[Bug bootstrap/53898] [4.8 regression] bootstrap failure: graphite-optimize-isl.c: ISO C forbids an empty translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53898 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-09 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 12:07:10 UTC --- Mine.
[Bug fortran/53885] seg. fault during assignment to allocatable component within type-bounded proc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53885 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-09 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-07-09 12:11:46 UTC --- I can confirm the runtime segfault with gfortran 4.6.3, but version 4.7.1 (and trunk) seems to work correctly. I hope you can update to 4.7.
[Bug lto/53895] [4.7/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53895 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-07-09 12:20:41 UTC --- yes it does ld -v GNU ld version 2.22.52.0.1-10.fc17 20120131 [innocent@pcphsftkepler bugs48]$ c++ thread.cpp -pthread -std=gnu++0x -O2 -flto -Wl,-v collect2 version 4.8.0 20120623 (experimental) [trunk revision 188906] /home/innocent/gccDir/bin/ld -plugin /home/innocent/gccDir/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/liblto_plugin.so -plugin-opt=/home/innocent/gccDir/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccm8JDgc.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /lib/../lib64/crt1.o /lib/../lib64/crti.o /home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbegin.o -L/home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0 -L/home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../.. /tmp/ccUiBvi2.o -v -lstdc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtend.o /lib/../lib64/crtn.o GNU ld version 2.22.52.0.1-10.fc17 20120131 [innocent@pcphsftkepler bugs48]$ mv ~/gccDir/bin/ld.gold ~/gccDir/bin/ld [innocent@pcphsftkepler bugs48]$ c++ thread.cpp -pthread -std=gnu++0x -O2 -flto -Wl,-v collect2 version 4.8.0 20120623 (experimental) [trunk revision 188906] /home/innocent/gccDir/bin/ld -plugin /home/innocent/gccDir/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/liblto_plugin.so -plugin-opt=/home/innocent/gccDir/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccJLE7SG.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /lib/../lib64/crt1.o /lib/../lib64/crti.o /home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbegin.o -L/home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0 -L/home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../.. /tmp/ccevajLa.o -v -lstdc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtend.o /lib/../lib64/crtn.o GNU gold (version 2.22.52.0.1-10.fc17 20120131) 1.11 /home/innocent/gccDir/bin/ld: error: /home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.so: symbol 'std::__once_callable' used as both __thread and non-__thread /home/innocent/gccDir/bin/ld: /tmp/ccevajLa.o: previous definition here /home/innocent/gccDir/bin/ld: error: /home/innocent/gccDir/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.so: symbol 'std::__once_call' used as both __thread and non-__thread /home/innocent/gccDir/bin/ld: /tmp/ccevajLa.o: previous definition here collect2: error: ld returned 1 exit status On 9 Jul, 2012, at 4:28 PM, hjl.tools at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53895 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-09 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-07-09 06:28:27 UTC --- Does it work with BFD linker? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53876 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-09 CC||janus at gcc dot gnu.org Summary|ICE: OOP Class array|[4.8 Regression] [OOP] ICE ||with class array Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-07-09 12:24:41 UTC --- (In reply to comment #0) oop_class_array.f90: In function ‘display_population’: oop_class_array.f90:111:0: internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:161 CALL self%indv(i)%display() ^ I can confirm this ICE with trunk. However, gfortran 4.7.1 compiles the test case cleanly, so apparently it is a regression. With 4.7 one gets a segfault at runtime (invalid memory reference on line 106). Thanks for the bug report!
[Bug bootstrap/53898] [4.8 regression] bootstrap failure: graphite-optimize-isl.c: ISO C forbids an empty translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53898 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 12:40:56 UTC --- Author: rguenth Date: Mon Jul 9 12:40:51 2012 New Revision: 189374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189374 Log: 2012-07-09 Richard Guenther rguent...@suse.de PR bootstrap/53898 * graphite-optimize-isl.c: Make sure CU is not empty. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-optimize-isl.c
[Bug bootstrap/53898] [4.8 regression] bootstrap failure: graphite-optimize-isl.c: ISO C forbids an empty translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53898 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 12:40:56 UTC --- Author: rguenth Date: Mon Jul 9 12:40:51 2012 New Revision: 189374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189374 Log: 2012-07-09 Richard Guenther rguent...@suse.de PR bootstrap/53898 * graphite-optimize-isl.c: Make sure CU is not empty. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-optimize-isl.c --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 12:41:25 UTC --- Fixed.
[Bug bootstrap/53898] [4.8 regression] bootstrap failure: graphite-optimize-isl.c: ISO C forbids an empty translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53898 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 12:41:25 UTC --- Fixed.
[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53876 --- Comment #2 from janus at gcc dot gnu.org 2012-07-09 12:44:48 UTC --- Here is a reduced test case for the ICE (4.8 regression): IMPLICIT NONE TYPE :: individual REAL, DIMENSION(:), ALLOCATABLE :: genes END TYPE CLASS(individual), DIMENSION(:), ALLOCATABLE :: indv INTEGER :: i CALL display_indv(indv(1)) CONTAINS SUBROUTINE display_indv(self) CLASS(individual), INTENT(IN) :: self END SUBROUTINE END
[Bug lto/53895] [4.7/4.8 Regression][lto] symbol 'std::__once_callable' used as both __thread and non-__thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53895 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-07-09 13:15:34 UTC --- (In reply to comment #2) yes it does ld -v GNU ld version 2.22.52.0.1-10.fc17 20120131 [innocent@pcphsftkepler bugs48]$ c++ thread.cpp -pthread -std=gnu++0x -O2 -flto -Wl,-v It sounds like a gold bug.
[Bug target/53283] [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283 --- Comment #12 from Sean McGovern gseanmcg at gmail dot com 2012-07-09 13:32:25 UTC --- This was OK'ed on the ML but not committed yet?
[Bug c++/53899] New: [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899
Bug #: 53899
Summary: [C++0x] undefined reference to
std::atomicboost::lockfree::detail::tagged_ptr...
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nnel...@infowest.com
Thank you for your constantly used GCC compiler.
boost lockfree and boost atomic have been accepted by boost and should shortly
be in the boost distribution. The current programs are available at
http://tim.klingt.org/boost_lockfree.tar.gz
The following program when compiled and executed from libs/lockfree/test
(including the other required boost distribution components), a folder in the
prior gz, will work OK using
g++ bench_3.cpp -o bench_3
but gives errors of the following kind when using
g++ -std=c++0x bench_3.cpp -o bench_3
undefined reference to
`std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong,
boost::lockfree::caching_freelist_t, std::allocatorlong ::node
::load(std::memory_order) const'
undefined reference to
`std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong,
boost::lockfree::caching_freelist_t, std::allocatorlong ::node
::compare_exchange_weak(boost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong,
boost::lockfree::caching_freelist_t, std::allocatorlong ::node,
boost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong,
boost::lockfree::caching_freelist_t, std::allocatorlong ::node,
std::memory_order)'
undefined reference to
`std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong,
boost::lockfree::caching_freelist_t, std::allocatorlong ::node
::store(boost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong,
boost::lockfree::caching_freelist_t, std::allocatorlong ::node,
std::memory_order)'
This item may be along the line given in
Bug 49445 [C++0x] Undefined reference to std::atomicfloat operator float
Thank you.
Neil
// bench_3.cpp
#include ../../../boost/lockfree/fifo.hpp
int elements = 100;
int iterations = 50;
#define FIFO \
boost::lockfree::fifolong f(elements);
#define FIFO_FULL \
boost::lockfree::fifolong f(elements); \
for (int i = 0; i != elements; ++i) \
f.enqueue_unsafe(i); \
__attribute__ ((noinline))
__attribute__ ((flatten))
void test_fifo_push(void)
{
FIFO
for (int i = 0; i != elements; ++i)
f.enqueue(i);
}
__attribute__ ((noinline))
__attribute__ ((flatten))
void test_fifo_pop(void)
{
FIFO_FULL
long out;
for (int i = 0; i != elements; ++i)
f.dequeue(out);
}
int main()
{
for (int i = 0; i != iterations; ++i)
test_fifo_push();
for (int i = 0; i != iterations; ++i)
test_fifo_pop();
}
[Bug c/53871] Please warn about endless loops if they are obvious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-07-09 13:59:58 UTC --- (If I had time to to that, I wouldn't have put it on the wishlist but created a patch.) I have thought a lot how to attract more and new developers to GCC who will be willing to develop things that are not a priority for current developers, but I don't have any solution to offer. It is a difficult problem: You and I see value in your proposal, but not enough value to compensate for the required time we would need to dedicate to it. The only solution is to have enough developers so that the time dedicated by each of them is small enough to be worth it. But there is not such pool of developers. Maybe it's time for a gcc static analyzer... In terms of technology, never has been a better time than now: GCC internals have never been as clean and re-usable, there is some interest in modularization, there is now the possibility of creating powerful plugins, etc. However, in terms of human resources, there is simply no one interested in working on this, for the reasons given above. Hence, someone new will need to appear: either a new company, a new group of developers, or a charismatic and committed developer that can rally existing developers around him/her.
[Bug c++/53882] [4.7/4.8 Regression] ICE in type_contains_placeholder_1, at tree.c:3015
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53882 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-07-09 14:11:11 UTC --- Author: jason Date: Mon Jul 9 14:11:01 2012 New Revision: 189386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189386 Log: PR c++/53882 * tree.c (type_contains_placeholder_1): Handle NULLPTR_TYPE. (type_hash_eq): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr29.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug c++/53826] [4.8 Regression] [alpha]: ICE in fold_convert_loc, at fold-const.c:2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53826 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-07-09 14:11:26 UTC --- Author: jason Date: Mon Jul 9 14:11:16 2012 New Revision: 189387 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189387 Log: PR c++/53826 * tree.c (build_zero_cst): Handle NULLPTR_TYPE. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree.c
[Bug c++/53882] [4.7/4.8 Regression] ICE in type_contains_placeholder_1, at tree.c:3015
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53882 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-07-09 14:11:11 UTC --- Author: jason Date: Mon Jul 9 14:11:01 2012 New Revision: 189386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189386 Log: PR c++/53882 * tree.c (type_contains_placeholder_1): Handle NULLPTR_TYPE. (type_hash_eq): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr29.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-07-09 14:11:47 UTC --- Author: jason Date: Mon Jul 9 14:11:33 2012 New Revision: 189388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189388 Log: PR c++/53882 * tree.c (type_contains_placeholder_1): Handle NULLPTR_TYPE. (type_hash_eq): Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/nullptr29.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree.c
[Bug c++/53882] [4.7/4.8 Regression] ICE in type_contains_placeholder_1, at tree.c:3015
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53882 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-07-09 14:11:47 UTC --- Author: jason Date: Mon Jul 9 14:11:33 2012 New Revision: 189388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189388 Log: PR c++/53882 * tree.c (type_contains_placeholder_1): Handle NULLPTR_TYPE. (type_hash_eq): Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/nullptr29.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree.c
[Bug c++/53899] [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 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 2012-07-09 14:13:12 UTC --- (In reply to comment #0) This item may be along the line given in Bug 49445 [C++0x] Undefined reference to std::atomicfloat operator float It's the same issue, already fixed in 4.7.0 It's not going to be fixed in 4.6, the Boost.lockfree authors will need to change their code to support GCC 4.6 *** This bug has been marked as a duplicate of bug 49445 ***
[Bug libstdc++/49445] [C++0x] Undefined reference to std::atomicfloat operator float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||nnelson at infowest dot com --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 14:13:12 UTC --- *** Bug 53899 has been marked as a duplicate of this bug. ***
[Bug c++/53899] [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 14:30:28 UTC --- The lockfree code is invalid anyway because boost::lockfree::detail::tagged_ptr doesn't have a trivial default constructor, so it can't be used with std::atomic
[Bug c++/53899] [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #3 from Neil Nelson nnelson at infowest dot com 2012-07-09 14:34:18 UTC --- Redi, Thank you for your very quick and detailed responses. Looks like I have some work to do on my end. I will copy this to the boost lockfree author. Neil On 07/09/2012 08:30 AM, redi at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 14:30:28 UTC --- The lockfree code is invalid anyway because boost::lockfree::detail::tagged_ptr doesn't have a trivial default constructor, so it can't be used with std::atomic
[Bug c++/53899] [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 14:45:26 UTC --- (In reply to comment #2) The lockfree code is invalid anyway because boost::lockfree::detail::tagged_ptr doesn't have a trivial default constructor, so it can't be used with std::atomic Actually ignore that part - I misread the spec.
[Bug c++/36797] ICE mangling __is_empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from Jason Merrill jason at gcc dot gnu.org 2012-07-09 14:55:16 UTC --- Fixed for 4.8.
[Bug c++/53900] New: Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 Bug #: 53900 Summary: Too optimistic on a alignment assert Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gael.guenneb...@gmail.com Created attachment 27766 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27766 an example triggering the issue. Since gcc 4.7 the assertion of the attached piece of code is resolved at compile-time while there is no guaranty, for instance when using a non-aligned memory allocator, or on some systems where function arguments cannot be aligned. Here is the output with gcc-4.7: $ g++-4.7 -m32 alignedassert.cpp ./a.out 0x8321008 0x832100c no assertion! And with gcc 4.6: $ g++-4.6 -m32 alignedassert.cpp ./a.out 0x9322008 a.out: alignedassert.cpp:12: Foo::Foo(): Assertion `(std::ptrdiff_t(array) std::ptrdiff_t(0xf))==0' failed. Aborted Or without the -m32 flag: $ g++-4.7 alignedassert.cpp ./a.out 0xde3010 0xde3014 $ g++-4.6 alignedassert.cpp ./a.out 0x1f03010 0x1f03014 a.out: alignedassert.cpp:12: Foo::Foo(): Assertion `(std::ptrdiff_t(array) std::ptrdiff_t(0xf))==0' failed. Aborted
[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
Daniel Schepler dschepler at gmail dot com changed:
What|Removed |Added
CC||dschepler at gmail dot com
--- Comment #34 from Daniel Schepler dschepler at gmail dot com 2012-07-09
15:02:42 UTC ---
(In reply to comment #31)
Just so you know, the proposed patch would break glibc builds. Here's a
reduced test case that reproduces an issue compiling glibc's s_isnan.c on
amd64...
extern int foo() __attribute__((__const__, __nothrow__));
extern int foo() __asm__(__GI_foo) __attribute__ ((visibility(hidden)));
extern __inline int __attribute__((__always_inline__)) foo() {
return 0;
}
int foo() {
return 0;
}
extern __typeof__(foo) __EI_foo __asm__(foo)
__attribute__((alias(__GI_foo)));
On Debian, gcc-4.6 compiles this code OK, while gcc-4.7 (which has this patch
applied) errors out with:
/tmp/pr33763_broken.c:9:24: error: '__EI_foo' aliased to external symbol
'__GI_foo'
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09 15:23:36 UTC --- You tell the compiler array is aligned, so what do you expect?
[Bug libstdc++/53901] New: [C++11] std::atomicT fails for type without trivial default constructor and trivial destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53901
Bug #: 53901
Summary: [C++11] std::atomicT fails for type without trivial
default constructor and trivial destructor
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
This fails to compile:
#include atomic
struct T {
T noexcept(false) { }
~T noexcept(false) { }
};
std::atomicT a;
g++ -std=c++11 ex.cc
In file included from ex.cc:1:0:
/home/jwakely/gcc/4.x/include/c++/4.8.0/atomic: In instantiation of 'struct
std::atomicT':
ex.cc:16:21: required from here
/home/wakelj/tools/Linux-f12-x86_64/4.8/include/c++/4.8.0/atomic:163:7: error:
function 'std::atomic_Tp::atomic() [with _Tp = T]' defaulted on its first
declaration with an exception-specification that differs from the implicit
declaration 'std::atomicT::atomic()'
atomic() noexcept = default;
^
/home/jwakely/gcc/4.x/include/c++/4.8.0/atomic:164:7: error: function
'std::atomic_Tp::~atomic() [with _Tp = T]' defaulted on its first declaration
with an exception-specification that differs from the implicit declaration
'std::atomicT::~atomic()'
~atomic() noexcept = default;
^
I believe the only requirement on the type T is that it's trivially copyable.
The defaulted constructor and destructor in atomicT need to be declared in
the class then defined as deleted later.
[Bug gcov-profile/53547] Changing the source file between -fprofile-generate and -fprofile-use can lead to performance degradation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53547 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-09 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-07-09 15:32:33 UTC --- Doctor, it hurts when i do this... It seems to me that one deserves a hard error if the source of the profile-use compilation is different from the profile-generate source. But perhaps you have your reasons, and can explain them?
[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #35 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09
15:39:35 UTC ---
(In reply to comment #34)
(In reply to comment #31)
Just so you know, the proposed patch would break glibc builds. Here's a
reduced test case that reproduces an issue compiling glibc's s_isnan.c on
amd64...
extern int foo() __attribute__((__const__, __nothrow__));
extern int foo() __asm__(__GI_foo) __attribute__ ((visibility(hidden)));
extern __inline int __attribute__((__always_inline__)) foo() {
return 0;
}
int foo() {
return 0;
}
extern __typeof__(foo) __EI_foo __asm__(foo)
__attribute__((alias(__GI_foo)));
On Debian, gcc-4.6 compiles this code OK, while gcc-4.7 (which has this patch
applied) errors out with:
/tmp/pr33763_broken.c:9:24: error: '__EI_foo' aliased to external symbol
'__GI_foo'
Yes, I know - the patch had fallout in the testsuite and I dropped the ball
on this bugreport.
[Bug go/53879] new glibc: sysinfo.go:5976:68: error: expected ‘{’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53879 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Ian Lance Taylor ian at airs dot com 2012-07-09 15:42:34 UTC --- This should be fixed by Jakub's patch that I committed a few hours ago. Thanks for reporting it.
[Bug libstdc++/53901] [C++11] std::atomicT fails for type without trivial default constructor and trivial destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53901 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 15:56:33 UTC --- Actually I'm not sure the testcase is valid. Defining the functions as defaulted outside the class does allow it to compile, but I think that might be a G++ bug. I'll get clarification from the LWG.
[Bug c++/53899] [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #5 from Neil Nelson nnelson at infowest dot com 2012-07-09 16:06:11 UTC --- Jonathan, (redi at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org) I installed g++-4.7 and obtained a good improvement over the prior results with the following output boost_lockfree/libs/lockfree/test$ g++-4.7 -std=c++0x bench_3.cpp -o bench_3 In file included from /usr/include/boost/lockfree/detail/atomic.hpp:15:0, from ../../../boost/lockfree/fifo.hpp:26, from bench_3.cpp:1: /usr/include/c++/4.7/atomic: In instantiation of ‘struct std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::freelist_node ’: /usr/include/boost/lockfree/detail/freelist.hpp:203:29: required from here /usr/include/c++/4.7/atomic:160:7: error: function ‘std::atomic_Tp::atomic() [with _Tp = boost::lockfree::detail::tagged_ptrboost::lockfree::detail::freelist_node]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::freelist_node ::atomic()’ /usr/include/c++/4.7/atomic: In instantiation of ‘struct std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong int, boost::lockfree::caching_freelist_t, std::allocatorlong int ::node ’: ../../../boost/lockfree/fifo.hpp:287:29: required from ‘class boost::lockfree::detail::fifolong int, boost::lockfree::caching_freelist_t, std::allocatorlong int ’ ../../../boost/lockfree/fifo.hpp:315:7: required from ‘class boost::lockfree::fifolong int’ bench_3.cpp:18:5: required from here /usr/include/c++/4.7/atomic:160:7: error: function ‘std::atomic_Tp::atomic() [with _Tp = boost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong int, boost::lockfree::caching_freelist_t, std::allocatorlong int ::node]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘std::atomicboost::lockfree::detail::tagged_ptrboost::lockfree::detail::fifolong int, boost::lockfree::caching_freelist_t, std::allocatorlong int ::node ::atomic()’ Tim Blechmann posted on the Boost list this morning he was doing final testing for the Boost 51 release. I will copy this to him in case he has an idea. My impression is that g++ -std=c++0x and boost lockfree are rather close. Neil On 07/09/2012 08:45 AM, redi at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 14:45:26 UTC --- (In reply to comment #2) The lockfree code is invalid anyway because boost::lockfree::detail::tagged_ptr doesn't have a trivial default constructor, so it can't be used with std::atomic Actually ignore that part - I misread the spec.
[Bug bootstrap/53902] New: make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 Bug #: 53902 Summary: make install fails on SunOS 5.11 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: karel.gar...@centrum.cz Hello, I'm trying to compile/install gcc 4.7.1 on my Solaris 11 Express/amd64 machine but `gmake install' fails in libitm with: gmake[7]: Entering directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/amd64/libitm' /bin/sh ./libtool --tag=CC --mode=link /var/tmp/gcc-obj/./gcc/xgcc -B/var/tmp/gcc-obj/./gcc/ -B/usr/local/gcc-4.7.1/i386-pc-solaris2.11/bin/ -B/usr/local/gcc-4.7.1/i386-pc-solaris2.11/lib/ -isystem /usr/local/gcc-4.7.1/i386-pc-solaris2.11/include -isystem /usr/local/gcc-4.7.1/i386-pc-solaris2.11/sys-include-Wall -Werror -Wc,-pthread -g -O2 -m64-Wl,-M,../../../../gcc-4.7.1/libitm/clearcap.map -m64 -o libitm.la -version-info 1:0:0 -Wl,-M,libitm.map-sun -rpath /usr/local/gcc-4.7.1/lib/amd64 aatree.lo alloc.lo alloc_c.lo alloc_cpp.lo barrier.lo beginend.lo clone.lo eh_cpp.lo local.lo query.lo retry.lo rwlock.lo useraction.lo util.lo sjlj.lo tls.lo method-serial.lo method-gl.lo method-ml.lo x86_sse.lo x86_avx.lo libtool: link: /var/tmp/gcc-obj/./gcc/xgcc -B/var/tmp/gcc-obj/./gcc/ -B/usr/local/gcc-4.7.1/i386-pc-solaris2.11/bin/ -B/usr/local/gcc-4.7.1/i386-pc-solaris2.11/lib/ -isystem /usr/local/gcc-4.7.1/i386-pc-solaris2.11/include -isystem /usr/local/gcc-4.7.1/i386-pc-solaris2.11/sys-include -m64 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libitm.so.1 -o .libs/libitm.so.1.0.0 .libs/aatree.o .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o .libs/method-ml.o .libs/x86_sse.o .libs/x86_avx.o-pthread -m64 -Wl,-M -Wl,../../../../gcc-4.7.1/libitm/clearcap.map -m64 -Wl,-M -Wl,libitm.map-sun ld: fatal: file /var/tmp/gcc-obj/./gcc/amd64/crtbegin.o; section [7].eh_frame and file .libs/sjlj.o; section [12].eh_frame have incompatibile attributes and cannot be merged into a single output section collect2: error: ld returned 1 exit status gmake[7]: *** [libitm.la] Error 1 gmake[7]: Leaving directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/amd64/libitm' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/amd64/libitm' gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/amd64/libitm' gmake[4]: *** [multi-do] Error 1 gmake[4]: Leaving directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/libitm' gmake[3]: *** [all-multi] Error 2 gmake[3]: Leaving directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/libitm' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/var/tmp/gcc-obj/i386-pc-solaris2.11/libitm' gmake[1]: *** [install-target-libitm] Error 2 gmake[1]: Leaving directory `/var/tmp/gcc-obj' gmake: *** [install] Error 2 karel@silence:/var/tmp/gcc-obj$ bootstrapping compiler is: $ gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802)
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 --- Comment #2 from Gael Guennebaud gael.guennebaud at gmail dot com 2012-07-09 16:12:07 UTC --- The problem is that it is not guaranteed to be effectively aligned, and it is nice to be able to detect when this happens to either abort with a clear message, trigger an exception, or even properly handle this case by disabling at runtime some optimizations. Anyway, if you disagree, I'm sure I'll find a workaround using, e.g., a non inlined intermediate function masking the origin of the pointer.
[Bug c++/53903] New: [C++11] Incompatible exception-specification allowed if member explicitly-defaulted after first declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53903
Bug #: 53903
Summary: [C++11] Incompatible exception-specification allowed
if member explicitly-defaulted after first declaration
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
struct T {
T() noexcept(false) { }
~T() noexcept(false) { }
};
struct A
{
A() noexcept;
~A() noexcept;
T t;
};
A::A() noexcept = default;
A::~A() noexcept = default;
This is accepted, but I think it shouldn't be.
[dcl.fct.def.default]/2
An explicitly-defaulted function [...] may have an explicit
exception-specification only if it is compatible (15.4) with
the exception specification on the implicit declaration.
The implicit declarations for A::A() and A::~A() would be noexcept(false) which
is not compatible.
If the functions are defaulted on their first declaration they get rejected:
struct T {
T() noexcept(false) { }
~T() noexcept(false) { }
};
struct A
{
A() noexcept = default;
~A() noexcept = default;
T t;
};
ex.cc:8:5: error: function 'A::A()' defaulted on its first declaration with an
exception-specification that differs from the implicit declaration 'A::A()'
A() noexcept = default;
^
ex.cc:9:5: error: function 'A::~A()' defaulted on its first declaration with an
exception-specification that differs from the implicit declaration 'A::~A()'
~A() noexcept = default;
^
The diagnostic specifically refers to defaulted on first declaration, implying
that's significant, but the [dcl.fct.def.default] wording above doesn't
distinguish between explicitly defaulting on the first declaration or after it.
[Bug c++/53899] [C++0x] undefined reference to std::atomicboost::lockfree::detail::tagged_ptr...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53899 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09 16:17:04 UTC --- See Bug 53901 I think GCC is correct about that too, the tagged_ptr class template should declare its default constructor and destructor to be noexcept in C++11 mode.
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-09
16:18:58 UTC ---
Well, I suggest you instead do
struct Foo
{
float array[4];
Foo()
{
std::cout array \n;
// check the object is really aligned
if (std::ptrdiff_t(array) std::ptrdiff_t(0xf)) != 0)
assert (false);
...code assuming array is aligned...
}
};
and the compiler will figure out that array is aligned in code dominated
by the alignment check.
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-07-09 16:28:24 UTC --- Passed testing on i386, bootstrapped fine on x86_64 multilib, I'd appreciate testing on 32-bit multilib platform. I've just completed a regtest with your patch on i386-pc-solaris2.10 (both 32 and 64-bit multilibs) without regressions. Rainer
[Bug libstdc++/53901] [C++11] std::atomicT fails for type without no-throw default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53901
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|[C++11] std::atomicT |[C++11] std::atomicT
|fails for type without |fails for type without
|trivial default constructor |no-throw default
|and trivial destructor |constructor
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-09
17:31:25 UTC ---
In my testccase T isn't trivially copyable because of its non-trivial
destructor, so only the constructor is relevant.
The fact G++ accepts it if the constructor is defaulted after its first
declaration is now PR 53903
N.B. it fails even if the default constructor isn't used:
#include atomic
struct T {
T() noexcept(false) { }
};
std::atomicT a{ T{} };
This appears to be a defect in the standard rather than a libstdc++ bug.
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #28 from Iain Sandoe iains at gcc dot gnu.org 2012-07-09 17:37:11 UTC --- (In reply to comment #27) Passed testing on i386, bootstrapped fine on x86_64 multilib, I'd appreciate testing on 32-bit multilib platform. I've just completed a regtest with your patch on i386-pc-solaris2.10 (both 32 and 64-bit multilibs) without regressions. likewise for i686-darwin9
[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53887 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-07-09 18:53:39 UTC --- Author: steven Date: Mon Jul 9 18:53:35 2012 New Revision: 189389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189389 Log: gcc/ PR tree-optimization/53887 * tree-cfg.c (group_case_labels_stmt): Make non-static. * tree-flow.h (group_case_labels_stmt): Add prototype. * tree-switch-conversion.c (process_switch): Use group_case_labels_stmt to pre-process every switch. testsuite/ PR tree-optimization/53887 * gcc.dg/pr53887.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr53887.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h trunk/gcc/tree-switch-conversion.c
[Bug target/53283] [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283 --- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2012-07-09 19:22:03 UTC --- Author: iains Date: Mon Jul 9 19:21:59 2012 New Revision: 189391 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189391 Log: PR target/53283 * config/i386/i386.c (ix86_fold_builtin): Call SUBTARGET_FOLD_BUILTIN if defined. * config/darwin.h: Rename TARGET_FOLD_BUILTIN to SUBTARGET_FOLD_BUILTIN. * config/rs6000/darwin.h: Map TARGET_FOLD_BUILTIN onto SUBTARGET_FOLD_BUILTIN. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/config/i386/i386.c trunk/gcc/config/rs6000/darwin.h
[Bug c/53904] New: trunk has valgrind errors for c-c++-common/torture/complex-sign-mul.c on x86-64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53904 Bug #: 53904 Summary: trunk has valgrind errors for c-c++-common/torture/complex-sign-mul.c on x86-64. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: zad...@naturalbridge.com built the trunk on x86-64 under ubuntu. i know that this bug is at least as old as r 188999 because that is when i first saw it, but it is still there as of r 189386 from today. Bug shows up at all -O levels. shows up on my private port also, but i guess that is not really any use to anyone else. But it causes an ice there so that is how i found it. valgrind ../.././cc1 -quiet -v -iprefix /home/zadeck/gcc/gbBaseline/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/ -isystem ../.././include -isystem ../.././include-fixed -D NO_TRAMPOLINES -D NO_TRAMPOLINES /home/zadeck/gcc/c2wide/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-mul.c -quiet -dumpbase complex-sign-mul.c -mtune=generic -march=x86-64 -auxbase complex-sign-mul -g -O3 -std=gnu99 -version -fno-diagnostics-show-caret -o /tmp/ccd2Ykcd.s ==13911== Memcheck, a memory error detector ==13911== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==13911== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==13911== Command: ../.././cc1 -quiet -v -iprefix /home/zadeck/gcc/gbBaseline/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/ -isystem ../.././include -isystem ../.././include-fixed -D NO_TRAMPOLINES -D NO_TRAMPOLINES /home/zadeck/gcc/c2wide/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-mul.c -quiet -dumpbase complex-sign-mul.c -mtune=generic -march=x86-64 -auxbase complex-sign-mul -g -O3 -std=gnu99 -version -fno-diagnostics-show-caret -o /tmp/ccd2Ykcd.s ==13911== GNU C (GCC) version 4.8.0 20120709 (experimental) [trunk revision 157801] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /home/zadeck/gcc/gbBaseline/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include ignoring nonexistent directory /home/zadeck/gcc/gbBaseline/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed ignoring nonexistent directory /home/zadeck/gcc/gbBaseline/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed ignoring nonexistent directory /usr/local/lib/../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: ../.././include ../.././include-fixed /usr/local/include /usr/include End of search list. GNU C (GCC) version 4.8.0 20120709 (experimental) [trunk revision 157801] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 91429a3f3152806ffebd3a415263526d ==13911== Invalid read of size 8 ==13911==at 0xD688C9: search_line_sse2 (lex.c:393) ==13911==by 0xD68AA1: _cpp_clean_line (lex.c:742) ==13911==by 0xD694C7: _cpp_get_fresh_line (lex.c:2035) ==13911==by 0xD6AD60: _cpp_lex_direct (lex.c:2100) ==13911==by 0xD6BB46: _cpp_lex_token (lex.c:1974) ==13911==by 0xD6FF7F: cpp_get_token_1 (macro.c:2357) ==13911==by 0x541EEF: c_lex_with_flags (c-lex.c:299) ==13911==by 0x4F27C3: c_lex_one_token (c-parser.c:218) ==13911==by 0x4F2B02: c_parser_peek_token (c-parser.c:400) ==13911==by 0x501E56: c_parser_compound_statement_nostart (c-parser.c:412) ==13911==by 0x503898: c_parser_compound_statement (c-parser.c:4072) ==13911==by 0x4FFA8B: c_parser_declaration_or_fndef (c-parser.c:1757) ==13911== Address 0x5b85b40 is 1,712 bytes inside a block of size 1,716 alloc'd ==13911==at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==13911==by 0xD9691C: xrealloc (xmalloc.c:179) ==13911==by 0xD5D0CB: _cpp_convert_input (charset.c:1734) ==13911==by 0xD65F72: read_file (files.c:681) ==13911==by 0xD66A1A: _cpp_stack_file (files.c:756) ==13911==by 0xD68335: cpp_read_main_file (init.c:600) ==13911==by 0x5482B1: c_common_post_options (c-opts.c:1063) ==13911==by 0x89F218: toplev_main (toplev.c:1216) ==13911==by 0x573576C: (below main) (libc-start.c:226) ==13911== ==13911== Invalid read of size 8 ==13911==at 0xD688B3: search_line_sse2 (lex.c:381) ==13911==by 0xD68AA1: _cpp_clean_line (lex.c:742) ==13911==by 0xD694C7: _cpp_get_fresh_line (lex.c:2035) ==13911==by 0xD6AD60
[Bug bootstrap/51094] [4.7 Regression] Bootstrap failure at revision 181279 on non-ELF targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094 --- Comment #29 from jimis jimis at gmx dot net 2012-07-09 19:57:22 UTC --- Thanks guys, sent to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00345.html
[Bug c++/53733] [C++11][DR 1402] Move constructor/assignment operator too often deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53733 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-09 20:49:31 UTC --- Jason, this is the PR/DR we were talking about.
[Bug middle-end/53887] [4.8 Regression] ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53887 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-07-09 21:33:16 UTC --- .
[Bug objc/53905] New: -Wformat-nonliteral gives false positives with __attribute__((format(NSString,...)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53905
Bug #: 53905
Summary: -Wformat-nonliteral gives false positives with
__attribute__((format(NSString,...)))
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: naes...@gmail.com
iMac:hacking user$ gcc-fsf-4.7 --version
gcc-fsf-4.7 (GCC) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
iMac:hacking user$ cat NSString_format_bug.
NSString_format_bug.m NSString_format_bug.m~ NSString_format_bug.o
iMac:hacking user$ cat NSString_format_bug.m
#pragma GCC diagnostic error -Wformat
#pragma GCC diagnostic error -Wformat-nonliteral
@class NSString;
extern void NSLog(NSString *, ...) __attribute__((format(NSString, 1, 2)));
void foo ()
{
NSLog(@Hi!);
}
iMac:hacking user$ gcc-fsf-4.7 -c NSString_format_bug.m
NSString_format_bug.m: In function ‘foo’:
NSString_format_bug.m:11:3: error: format not a string literal and no format
arguments [-Werror=format-nonliteral]
cc1obj: some warnings being treated as errors
[Bug libstdc++/53906] New: Runtime crash on ARM linux when using std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53906
Bug #: 53906
Summary: Runtime crash on ARM linux when using std::thread
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: casca...@qualcomm.com
Using the following simple test on an ARM linux platform with gcc 4.7.1 and
-march=armv7-a results in a crash.
Here is the example:
#include iostream
#include thread
#include vector
using namespace std;
void worker(int tid) { cout Running in thread tid endl; }
int main() {
int nThreads = 4;
vectorthread threads;
for (int i = 0; i nThreads; ++i)
threads.push_back(thread(worker, i));
for(auto t : threads) t.join();
return 0;
}
Compiling with gcc-4.7:
/opt/local/bin/gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=gcc-4.7
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/armv7l-unknown-linux-gnueabi/4.7.1/lto-wrapper
Target: armv7l-unknown-linux-gnueabi
Configured with: /tmp/src/gcc/gcc-4.7.1/configure --prefix=/opt/local
--program-suffix=-4.7 --enable-shared --disable-nls --with-system-zlib
--enable-threads=posix --enable-tls --enable-plugin --enable-lto
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: posix
gcc version 4.7.1 (GCC)
Platform: ARM Cortex A9, Linux 3.3.0 kernel
Here is the output when compiled with the default arch:
prompt /opt/local/bin/g++-4.7 -std=c++11 -ggdb -pthread threadtest.cc -o
t_armv5
prompt ./t_armv5
Running in thread 2
Running in thread 0
Running in thread 1
Running in thread 3
And when compiled with the additional -march=armv7-a
prompt /opt/local/bin/g++-4.7 -march=armv7-a -std=c++11 -ggdb -pthread
threadtest.cc -o t_armv7
prompt ./t_armv7
pure virtual method called
pure virtual method called
pure virtual method called
terminate called without an active exception
terminate called recursively
Abort (core dumped)
[Bug testsuite/20771] Duplicate PCH test names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20771 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2012-07-09 22:10:46 UTC --- Author: janis Date: Mon Jul 9 22:10:40 2012 New Revision: 189393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189393 Log: Backport from mainline. 2012-06-28 Janis Johnson jani...@codesourcery.com * g++.dg/cpp0x/nullptr19.c: Remove exta directives on same line. * g++.dg/template/error46.C: Add missing comment to dg-message. * g++.dg/template/crash107.C: Likewise. * g++.dg/template/error47.C: Likewise. * g++.dg/template/crash108.C: Likewise. * g++.dg/overload/operator5.C: Likewise. * gcc.dg/Wstrict-aliasing-converted-assigned.c: Fix syntax errors in dg-message directives, add comments. 2012-06-26 Janis Johnson jani...@codesourcery.com * lib/scandump.exp (scan-dump, scan-dump-not, scan-dump-dem, scan-dump-dem-not): Use printable pattern in test name. 2012-06-25 Janis Johnson jani...@codesourcery.com * lib/target-supports-dg.exp (testname-for-summary): New. * lib/profopt.exp (profopt_execute): Define testname_with_flags. * lib/gcc-dg.exp (cleanup-coverage-files, cleanup-repo-notes, cleanup-stack-usage, cleanup-dump, cleanup-saved-temps, scan-module, scan-module-absence, output-exists, output-exists-not: Use testname-for-summary. (dg-test): Clean up testname_with_flags. * lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden, scan-not-hidden, scan-file, scan-file-not, scan-stack-usage, scan-stack-usage-not, scan-assembler-times, scan-assembler-dem, scan-assembler-dem-not, object-size: Use testname-for-summary. * lib/gcov.exp (run-gcov): Likewise. * lib/scandump.exp (scan-dump, scan-dump-times, scan-dump-not, scan-dump-dem, scan-dump-dem-note): Likewise. * lib/profopt.exp: Make prof_option_list local to profopt-execute. * g++.dg/tree-prof/tree-prof.exp (PROFOPT_OPTIONS): Define after including profopt.opt; save and restore existing value. * g++.dg/bprob/bprob.exp: Likewise. * gcc.dg/matrix/matrix.exp: Likewise. * gcc.dg/tree-prof/tree-prof.exp: Likewise. * gcc.misc-tests/bprob.exp: Likewise; also replace formerly-ignored PROFOPT_OPTIONS. 2012-06-15 Janis Johnson jano...@codesourcery.com * lib/gcov.exp (verify-lines, verify-branches, verify-calls): Use testname that includes flags, passed in as new argument, in pass/fail messages. (run_gcov): Get testname from dg-test, use it in pass/fail messages and pass it to verify-* procedures. * g++.dg/torture/stackalign/stackalign.exp: Combine stack alignment torture options with usual torture options. * g++.dg/cpp0x/auto27.C: Add comments to checks for multiple messages reported for one line of source code. * g++.dg/cpp0x/constexpr-decl.C: Likewise. * g++.dg/cpp0x/decltype2.C: Likewise. * g++.dg/cpp0x/decltype3.C: Likewise. * g++.dg/cpp0x/lambda/lambda-syntax1.C: Likewise. * g++.dg/cpp0x/regress/error-recovery1.C: Likewise. * g++.dg/cpp0x/static_assert3.C: Likewise. * g++.dg/cpp0x/udlit-cpp98-neg.C: Likewise. * g++.dg/cpp0x/udlit-shadow-neg.C: Likewise. * g++.dg/cpp0x/union1.C: Likewise. * g++.dg/cpp0x/variadic-ex10.C: Likewise. * g++.dg/cpp0x/variadic-ex14.C: Likewise. * g++.dg/cpp0x/variadic2.C: Likewise. * g++.dg/cpp0x/variadic20.C: Likewise. * g++.dg/cpp0x/variadic74.C: Likewise. * g++.dg/diagnostic/bitfld2.C: Likewise. * g++.dg/ext/attrib44.C: Likewise. * g++.dg/ext/no-asm-1.C: Likewise. * g++.dg/other/error34.C: Likewise. * g++.dg/parse/crash46.C: Likewise. * g++.dg/parse/error10.C: Likewise. * g++.dg/parse/error2.C: Likewise. * g++.dg/parse/error3.C: Likewise. * g++.dg/parse/error36.C: Likewise. * g++.dg/parse/error8.C: Likewise. * g++.dg/parse/error9.C: Likewise. * g++.dg/parse/parser-pr28152-2.C: Likewise. * g++.dg/parse/parser-pr28152.C: Likewise. * g++.dg/parse/template25.C: Likewise. * g++.dg/parse/typename11.C: Likewise. * g++.dg/tc1/dr147.C: Likewise. * g++.dg/template/deduce3.C: Likewise. * g++.dg/template/koenig9.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/warn/pr12242.C: Likewise. * g++.dg/warn/pr30551-2.C: Likewise. * g++.dg/warn/pr30551.C: Likewise. * g++.old-deja/g++.other/typename1.C: Likewise. * g++.old-deja/g++.pt/niklas01a.C: Likewise. 2012-06-13 Janis Johnson jani...@codesourcery.com PR testsuite/20771 * lib/dg-pch.exp (dg-flags-pch): Add flags to make compile lines in test summary unique. * lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden, scan-not-hiddent, scan-file, scan-file-not, scan-stack-usage, scan-stack-usage-not): Don't strip torture options from test name. * lib/scandump.exp (scan-dump-times): Use printable version of regexp in test summary line. *
[Bug target/53906] Runtime crash on ARM linux when using std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53906 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||EH, wrong-code Component|libstdc++ |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-09 22:11:46 UTC --- What glibc version are you using?
[Bug target/53906] Runtime crash on ARM linux when using std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53906 --- Comment #2 from cascaval at qualcomm dot com 2012-07-09 22:29:14 UTC --- apt-cache show libc6-dev Package: libc6-dev Priority: optional Section: libdevel Installed-Size: 9544 Maintainer: GNU Libc Maintainers debian-gl...@lists.debian.org Architecture: armel Source: eglibc Version: 2.11.3-3 Provides: libc-dev
[Bug target/53886] Seg fault in sh_insn_length_adjustment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-09 22:39:29 UTC --- Author: olegendo Date: Mon Jul 9 22:39:25 2012 New Revision: 189394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189394 Log: PR target/53886 * config/sh/sh.c (sequence_insn_p): New function. (find_barrier, sh_insn_length_adjustment): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug target/53907] New: gcc uses unaligned load when aligned load was requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53907
Bug #: 53907
Summary: gcc uses unaligned load when aligned load was
requested
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nel...@seznam.cz
A gcc 4.7 and 4.8 emit movdqu instead movdqa for aligned load instrinc.
#include emmintrin.h
__m128i x(char *s){
__m128i sz,z,mvec;
s-=((unsigned long) s)%16;
sz=_mm_load_si128(s);
return sz;
}
Output of gcc -O3 -S follows
.file int.c
.text
.p2align 4,,15
.globl x
.type x, @function
x:
.LFB517:
.cfi_startproc
movq %rdi, %rax
andl $15, %eax
negq %rax
movdqu (%rdi,%rax), %xmm0
ret
.cfi_endproc
.LFE517:
.size x, .-x
.ident GCC: (Debian 20120704-1) 4.8.0 20120704 (experimental) [trunk
revision 189247]
.section .note.GNU-stack,,@progbits
[Bug c++/53733] [C++11][DR 1402] Move constructor/assignment operator too often deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53733 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2012-07-10 00:03:27 UTC --- Author: jason Date: Tue Jul 10 00:03:23 2012 New Revision: 189396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189396 Log: DR 1402 PR c++/53733 * cp-tree.h (FNDECL_SUPPRESS_IMPLICIT_DECL): New. (struct lang_decl_fn): Add suppress_implicit_decl field. * method.c (implicitly_declare_fn): Check it. (process_subob_fn): Add no_implicit_p parm. (walk_field_subobs, synthesized_method_walk): Likewise. (maybe_explain_implicit_delete): Adjust. (explain_implicit_non_constexpr): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/defaulted21.C
[Bug c++/53733] [C++11][DR 1402] Move constructor/assignment operator too often deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53733 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-07-10 00:05:53 UTC --- Author: jason Date: Tue Jul 10 00:05:50 2012 New Revision: 189398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189398 Log: DR 1402 PR c++/53733 * cp-tree.h (FNDECL_SUPPRESS_IMPLICIT_DECL): New. (struct lang_decl_fn): Add suppress_implicit_decl field. * method.c (implicitly_declare_fn): Check it. (process_subob_fn): Add no_implicit_p parm. (walk_field_subobs, synthesized_method_walk): Likewise. (maybe_explain_implicit_delete): Adjust. (explain_implicit_non_constexpr): Adjust. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/defaulted36.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/cp-tree.h branches/gcc-4_7-branch/gcc/cp/method.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/defaulted21.C
[Bug c++/53733] [C++11][DR 1402] Move constructor/assignment operator too often deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53733 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.2 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-07-10 00:07:16 UTC --- Fixed.
[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit), at least with MacPorts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883 --- Comment #4 from Daryle Walker dwalker07 at yahoo dot com 2012-07-10 01:32:12 UTC --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #0) (Should I try building GCC 4.7.1 straight from you guys, without going through MacPorts?) Yes, probably. I'm working on that now ...And here's what I tried: //--- svn co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_7_1_release gcc cd gcc nano README nano contrib/gcc_update ./contrib/gcc_update --touch cd .. mkdir gcc-obj cd gcc-obj ../gcc/configure --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local make //--- (I'm using GMP, MPFR, and MPC from MacPorts. Note that it used the system compiler, Apple's GCC 4.0.1, and not anything from MacPorts for the first compiler phase.) It didn't build all the way through; here's the last few lines: //--- checking for gawk... awk checking whether make sets $(MAKE)... yes checking for --enable-version-specific-runtime-libs... no checking for style of include used by make... GNU checking for powerpc-apple-darwin8.11.0-gcc... /Users/daryle/Documents/Projects/GCC/gcc-obj/./gcc/xgcc -B/Users/daryle/Documents/Projects/GCC/gcc-obj/./gcc/ -B/usr/local/powerpc-apple-darwin8.11.0/bin/ -B/usr/local/powerpc-apple-darwin8.11.0/lib/ -isystem /usr/local/powerpc-apple-darwin8.11.0/include -isystem /usr/local/powerpc-apple-darwin8.11.0/sys-include -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: in `/Users/daryle/Documents/Projects/GCC/gcc-obj/powerpc-apple-darwin8.11.0/ppc64/libquadmath': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libquadmath] Error 1 make: *** [all] Error 2 [daryle:gcc-obj]$ l //--- It seems that it tried to build libquadmath thinking all PowerPC systems are 64-bit, while mine is 32-bit. I didn't reach the error I reported with MacPorts' build yet. Is there any way to force libquadmath to compile in 32-bit mode? (If that's impossible, is it skippable?) I'll try to attach the config.log file. I'll retry make when you guys let me know how to fix up libquadmath.
[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit), at least with MacPorts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883 --- Comment #5 from Daryle Walker dwalker07 at yahoo dot com 2012-07-10 01:34:10 UTC --- Created attachment 27767 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27767 The log from the failed make described in Comment 4
[Bug rtl-optimization/53908] New: [4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 Bug #: 53908 Summary: [4.7 Regression] csa removes needed memory load Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Host: x86_64-linux Target: x86_64-linux-gnu, cris-axis-elf, crisv32-axis-linux-gnu Created attachment 27768 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27768 Repeat with e.g. cc1 -O2 ba2.c Observed with gcc-4_7-branch revision 189394. The attached test-case calls is_basic(user_name) 0 is_digest(user_name) 0 with *user_name = NULL. The call to is_basic fails; returns 0 without writing to *user_name. The call to is_digest is successful and furthermore writes *user_name (a char **). Next, *user_item = find_user(*user_name) is called, but the load of *user_name after the is_digest call is lost; wrongly eliminated in favor of the load after the call to is_basic. A dump shows wrong code first in the .207r.csa pass (for crisv32-axis-linux-gnu, likely for x86_64 as well). The test-case does not expose the bug on trunk r189401. Not observed with a gcc-4.3-based toolchain (cris-*), not observed with (host) Debian 4.4.5-8. Unknown 4.5, 4.6.
[Bug c++/53909] New: internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:3560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53909
Bug #: 53909
Summary: internal compiler error: in gimplify_init_ctor_eval,
at gimplify.c:3560
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tud...@fb.com
constexpr constructors and multiple inheritance (non-virtual inheritance,
diamond pattern) don't mix; this causes an ICE with gcc 4.6.2 (minimized from
production code):
$ g++ -std=c++0x -g -o Bug Bug.cpp
Bug.cpp: In function ?int main()?:
Bug.cpp:10:19: internal compiler error: in gimplify_init_ctor_eval, at
gimplify.c:3560
struct B { };
struct C1 : B { };
struct C2 : B { };
struct A : C1, C2 {
constexpr A(int x) { }
};
int main() {
A a[] = {1, 2, 3};
return 0;
}
$ g++ --version
g++ (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1)
Copyright (C) 2011 Free Software Foundation, Inc.
[Bug c++/53909] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:3560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53909 --- Comment #1 from Tudor Bosman tudorb at fb dot com 2012-07-10 03:33:51 UTC --- Appears fixed in gcc 4.7.1.
[Bug c++/53909] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:3560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53909 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-10 03:40:23 UTC --- Two things, first this should have been reported to redhat since they are the ones which provided you GCC. Second, you said it seemed fixed in 4.7.1, as C++11 support is experimental there is no reason to keep this bug opened. So closing as fixed.
