[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 #6 from Andreas Schwab sch...@linux-m68k.org 2012-07-10 06:36:03 UTC --- *-darwin8 assumes ppc64 multilib, try --disable-multilib.
[Bug c++/53910] New: use -std=c++11 by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53910 Bug #: 53910 Summary: use -std=c++11 by default Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com g++ could use -std=c++11 by default
[Bug c++/53549] [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #10 from Conrad conradsand.arma at gmail dot com 2012-07-10 07:22:00 UTC --- Created attachment 27769 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27769 arma323.ii.gz Retested with gcc 4.7.1 and Armadillo 3.2.3 (latest upstream version). This time a related but different bug in GCC is exposed. arma323.ii.gz is the attached pre-processed source. Code compiles fine on gcc 4.4.6 and clang 3.0. /usr/local/bin/g++ arma323.cpp -o arma323 -O2 -Wall -pedantic In file included from /usr/include/armadillo:141:0, from arma323.cpp:2: /usr/include/armadillo_bits/Mat_bones.hpp:545:26: error: no members matching ‘arma::MateT::operator=’ in ‘class arma::MateT’ /usr/include/armadillo_bits/Mat_bones.hpp:546:27: error: no members matching ‘arma::MateT::operator()’ in ‘class arma::MateT’ In file included from /usr/include/armadillo:142:0, from arma323.cpp:2: /usr/include/armadillo_bits/Col_bones.hpp:175:27: error: no members matching ‘arma::ColeT::operator()’ in ‘class arma::ColeT’ In file included from /usr/include/armadillo:143:0, from arma323.cpp:2: /usr/include/armadillo_bits/Row_bones.hpp:173:27: error: no members matching ‘arma::RoweT::operator()’ in ‘class arma::RoweT’ GCC 4.7.1 was compiled directly from sources, using GCC 4.7.0 on a Fedora 17 machine. /usr/local/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure Thread model: posix gcc version 4.7.1 (GCC)
[Bug target/53911] New: [SH] Improve displacement addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53911 Bug #: 53911 Summary: [SH] Improve displacement addressing Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* The address re-basing for displacement addresses could be improved by looking at all the required displacements in a function. The current approach re-bases an address on certain alignments and just hopes that the new base address will be useful and that CSE will eliminate redundant address re-base calculations. Probably a target specific RTL pass is required to accomplish this. Since address re-base calculations require additional registers it has an impact on register allocation. Thus the pass should be ran sometime after combine and before reload. On the other hand, reload itself might generate displacement addresses to access pseudos on the stack, which also produces displacement addressings. Probably it would be useful to run the pass again after reload, too.
[Bug c/53871] Please warn about endless loops if they are obvious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 --- Comment #4 from Tim Ruehsen tim.ruehsen at gmx dot de 2012-07-10 07:58:26 UTC --- (In reply to comment #3) 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. There is not one solution, but a mixture of approaches may attract some developers. What about these Summer of Code things, why not writing articles for developer magazins. There is a need for good and easy tutorials about GIMPLE and gcc plugins. After your last post, I read about gcc plugins - very interesting indeed. A quick search revealed some articles/tutorials, but non of them gave me an instant kick to rush into. As far as I could see, you have to be an GIMPLE expert, before you start reading one of these articles. That might discourage some potential plugin developers. However, in terms of human resources, there is simply no one interested in working on this, ... I am a senior developer, and I use gcc every day. But I wasn't aware of gcc's plugin feature. Just spread the word and you might get some interested people.
[Bug bootstrap/53912] New: bootstrap fails at stage 2 with error: cast from 'void*' to 'long int' loses precision in ggc-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 Bug #: 53912 Summary: bootstrap fails at stage 2 with error: cast from 'void*' to 'long int' loses precision in ggc-common.c Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de bootstrap native x86_64-w64-mingw32 fails at stage 2: /SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/./prev-gcc/g++ -B/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/./prev-gcc/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.2/x86_64-w64-mingw32/bin/ -nostdinc++ -B/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs -B/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -I/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/prev-x86_64-w64-mingw32/libstdc++-v3/include -I/SCRATCH/tmp.pBPKMqodMC/src/gcc-4.7.2/libstdc++-v3/libsupc++ -L/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../../src/gcc-4.7.2/gcc -I../../../src/gcc-4.7.2/gcc/. -I../../../src/gcc-4.7.2/gcc/../include -I./../intl -I../../../src/gcc-4.7.2/gcc/../libcpp/include -I/SCRATCH/tmp.pBPKMqodMC/install/include -I/SCRATCH/tmp.pBPKMqodMC/install/include -I/SCRATCH/tmp.pBPKMqodMC/install/include -I../../../src/gcc-4.7.2/gcc/../libdecnumber -I../../../src/gcc-4.7.2/gcc/../libdecnumber/bid -I../libdecnumber -I/SCRATCH/tmp.pBPKMqodMC/install/include -I/SCRATCH/tmp.pBPKMqodMC/install/include ../../../src/gcc-4.7.2/gcc/ggc-common.c -o ggc-common.o ../../../src/gcc-4.7.2/gcc/ggc-common.c: In function 'int gt_pch_note_object(void*, void*, gt_note_pointers, gt_types_enum)': ../../../src/gcc-4.7.2/gcc/ggc-common.c:326:49: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ../../../src/gcc-4.7.2/gcc/ggc-common.c: In function 'void gt_pch_note_reorder(void*, void*, gt_handle_reorder)': ../../../src/gcc-4.7.2/gcc/ggc-common.c:359:44: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ../../../src/gcc-4.7.2/gcc/ggc-common.c: In function 'hashval_t saving_htab_hash(const void*)': ../../../src/gcc-4.7.2/gcc/ggc-common.c:370:10: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ../../../src/gcc-4.7.2/gcc/ggc-common.c: In function 'void relocate_ptrs(void*, void*)': ../../../src/gcc-4.7.2/gcc/ggc-common.c:443:45: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ../../../src/gcc-4.7.2/gcc/ggc-common.c: In function 'void write_pch_globals(const ggc_root_tab* const*, traversal_state*)': ../../../src/gcc-4.7.2/gcc/ggc-common.c:472:42: error: cast from 'void*' to 'long int' loses precision [-fpermissive] make[3]: *** [ggc-common.o] Error 1 make[3]: Leaving directory `/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/SCRATCH/tmp.pBPKMqodMC/gcc-4.7.2/gcc-4.7.2' make: *** [all] Error 2 If configured with --disable-build-poststage1-with-cxx bootstrap succeeds.
[Bug target/53854] ICE in find_constant_pool_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-07-10 08:23:33 UTC --- It is true that asm can occupy even zero bytes (or some bytes just in other sections, but not in text section), so even allowing a single constant pool reference in an inline asm might be too much (if you have thousands of such inline asms next to each other). No idea where would you reject the constant pool references for the asm, inline asm can use any kind of constraints.
[Bug bootstrap/53913] New: [4.8 regression] resource.c:1179:5: error: 'current_function_decl' undeclared broke m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53913 Bug #: 53913 Summary: [4.8 regression] resource.c:1179:5: error: 'current_function_decl' undeclared broke m68k bootstrap 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 build gcc-4.8-20120708 for m68k-linux fails with: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/tmp/gcc-4.8-20120708/gcc -I/tmp/gcc-4.8-20120708/gcc/. -I/tmp/gcc-4.8-20120708/gcc/../include -I/tmp/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/tmp/gcc-4.8-20120708/gcc/../libdecnumber -I/tmp/gcc-4.8-20120708/gcc/../libdecnumber/dpd -I../libdecnumber /tmp/gcc-4.8-20120708/gcc/resource.c -o resource.o /tmp/gcc-4.8-20120708/gcc/resource.c: In function 'init_resource_info': /tmp/gcc-4.8-20120708/gcc/resource.c:1179:5: error: 'current_function_decl' undeclared (first use in this function) /tmp/gcc-4.8-20120708/gcc/resource.c:1179:5: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [resource.o] Error 1 make[2]: Leaving directory `/tmp/objdir/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/tmp/objdir' make: *** [all] Error 2 Line 1175 is the conditional occurrence of EPILOGUE_USES(i). The m68k definition of EPILOGUE_USES references current_function_decl, and apparently nothing brings in the needed header (tree.h) to resource.c any more. 4.8-20120701 builds fine, so this is a recent regression. Appending an #include tree.h to the include block at the start of resource.c makes a cross-build work, but that may not be the preferred fix.
[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 08:48:24 UTC --- What platform are you running on (GCC configuration)? Please can you do some profiling and try to identify where the slowdown is coming from. We need more information if we are to progress this.
[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 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org 2012-07-10 08:52:47 UTC --- fixed on trunk, remaining CFString errors are a different problem, needs a new PR.
[Bug java/16132] Invalid double calculations on ARM (FPA)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16132 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 08:59:10 UTC --- FPA support has now been dropped in GCC.
[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 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.2 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-07-10 09:02:25 UTC --- Fixed for 4.7.2.
[Bug target/38692] ep9312/maverick code generation is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38692 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 09:03:07 UTC --- Maverick support has now been dropped from GCC.
[Bug rtl-optimization/53908] [4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-07-10 09:04:58 UTC --- I can reproduce on sparc64-linux: gcc 4.4, 4.5, and 4.8 generate working code, but 4.6 and 4.7 generate code that SEGVs. I wasn't able to reproduce on ARMv5 or m68k.
[Bug c/53904] 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 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-10 09:06:29 UTC --- It's an optimization.
[Bug target/53907] gcc uses unaligned load when aligned load was requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53907 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-10 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-10 09:08:17 UTC --- I will look at this. It seems that CCP does not properly figure out alignment here.
[Bug target/14352] New FP code not compiled for non-arm-elf targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14352 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 09:08:27 UTC --- The none EABI configuration of arm-linux is no longer supported.
[Bug rtl-optimization/53908] [4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug bootstrap/53912] [4.7 Regression] bootstrap fails at stage 2 with error: cast from 'void*' to 'long int' loses precision in ggc-common.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug bootstrap/53913] [4.8 regression] resource.c:1179:5: error: 'current_function_decl' undeclared broke m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53913 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/16314] EP9312 gcc: undefined reference to __divdf3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16314 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #14 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 09:10:18 UTC --- Maverick support has now been dropped from GCC.
[Bug target/53907] gcc uses unaligned load when aligned load was requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53907
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-10
09:16:29 UTC ---
s.0_2 = (sizetype) s_1(D);
D.4303_3 = s.0_2 15;
D.4304_4 = -D.4303_3;
s_5 = s_1(D) + D.4304_4;
sz_6 = MEM[(const __m128i * {ref-all})s_5];
return sz_6;
it's hard to see for GCC that s_5 is aligned because of the way it is computed.
If I change the source to use
#include emmintrin.h
__m128i x(char *s){
__m128i sz,z,mvec;
s=(char *)(((unsigned long) s) -16);
sz=_mm_load_si128(s);
return sz;
}
then GCC sees that s is aligned. The code generated for the re-alignment
is also simpler, thus we should do this transform somewhere.
I'll prepare a patch.
[Bug rtl-optimization/53908] [4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-07-10 10:11:15 UTC --- I can't reproduce on x86_64-linux, nor with a cross to sparc64-linux (only natively on sparc64-linux so far). HP: are you sure it fails on x86_64? I'll try to bisect natively on sparc64, but that will take ages...
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
Daniel Santos daniel.santos at pobox dot com changed:
What|Removed |Added
CC||daniel.santos at pobox dot
||com
--- Comment #13 from Daniel Santos daniel.santos at pobox dot com 2012-07-10
10:23:08 UTC ---
Well here's another test case for the same problem:
extern print_gt(void);
extern print_lt(void);
extern print_eq(void);
void cmp_and_branch(long a, long b)
{
long diff = a - b;
if (diff 0) {
print_gt();
} else if (diff 0) {
print_lt();
} else {
print_eq();
}
}
In this case, the result of the subtraction is directly used in the branch
code. However, gcc -O2 -S still generates this output:
.filegcc_cmp_and_branch_test2.c
.text
.p2align 4,,15
.globlcmp_and_branch
.typecmp_and_branch, @function
cmp_and_branch:
.LFB0:
.cfi_startproc
subq%rsi, %rdi
cmpq$0, %rdi
jg.L5
jne.L6
jmpprint_eq
.p2align 4,,10
.p2align 3
.L5:
jmpprint_gt
.p2align 4,,10
.p2align 3
.L6:
jmpprint_lt
.cfi_endproc
.LFE0:
.sizecmp_and_branch, .-cmp_and_branch
.identGCC: (Gentoo 4.7.1) 4.7.1
.section.note.GNU-stack,,@progbits
I'm using Gentoo x86_64:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.1/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/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.7.1/python
--enable-checking=release --enable-java-awt=gtk --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.7.1'
Thread model: posix
gcc version 4.7.1 (Gentoo 4.7.1)
I do hope this can be addressed sometime soon. Thanks.
[Bug c++/53531] ,,,, accepted as template arguments for variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53531
Niels Penneman niels at penneman dot org changed:
What|Removed |Added
CC||niels at penneman dot org
--- Comment #1 from Niels Penneman niels at penneman dot org 2012-07-10
10:37:34 UTC ---
Exactly the same behavior with both 4.6.3 and 4.7.1
Similar test case below. Adding a trailing comma to a list of template
arguments breaks the code but compiles successfully and without warnings. A
trailing comma in a template list of for instance boost::mpl::vector will make
the vector empty.
#
template typename ... Ts
struct S;
template typename T, typename ... Ts
struct ST, Ts ... { static constexpr int count = STs ...::count + 1; };
template typename T
struct ST { static constexpr int count = 1; };
int main()
{
return Schar, int, long,::count;
}
#
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/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 --disable-libmudflap
--disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
--enable-checking=release --disable-libgcj --disable-libquadmath
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.3,
pie-0.5.2'
Thread model: posix
gcc version 4.6.3 (Gentoo 4.6.3 p1.3, pie-0.5.2)
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.1/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/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 --disable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/python
--enable-checking=release --disable-libgcj --disable-libquadmath
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.1 p1.0,
pie-0.5.3'
Thread model: posix
gcc version 4.7.1 (Gentoo 4.7.1 p1.0, pie-0.5.3)
#
Command: g++ -Wall -Wextra -std=c++0x undef.cpp
Output: none, completes succesfully
Command: ./a.out ; echo $?
Output: 0
When omitting the trailing comma, return status of compiled application is 3 as
expected.
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507 --- Comment #14 from owner at bugs dot debian.org 2012-07-10 10:54:26 UTC --- Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message has not been forwarded to the package maintainers or other interested parties; you should ensure that the developers are aware of the problem you have entered into the system - preferably quoting the Bug reference number, #75773. If you wish to submit further information on this problem, please send it to 75773-qu...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
[Bug c++/53531] ,,,, accepted as template arguments for variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53531 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-10 11:01:40 UTC --- It's now rejected on trunk: c.cc:3:15: error: template argument 1 is invalid int i = S::undefined; ^ c.cc:3:15: error: template argument 2 is invalid c.cc:3:15: error: template argument 3 is invalid c.cc:3:15: error: template argument 4 is invalid c.cc:3:15: error: template argument 5 is invalid (I might have been using an older 4.8 snapshot when I reported the bug, not sure now.) Jason, any idea which patch fixed these cases and if we need anything in the testsuite to prevent regressions before closing it?
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 --- Comment #4 from Gael Guennebaud gael.guennebaud at gmail dot com 2012-07-10 11:09:16 UTC --- Created attachment 27770 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27770 Another demonstration of the issue using std::vector Note that when we declare: __attribute__((aligned(16))) float array[4]; we request GCC to give us an aligned array, and we are not telling gcc that array is aligned that is slightly different. I attached another example demonstrating the problem: a simple declaration like: std::vectorFoo vec(5); generates unaligned arrays that are not caught by assertion because it has been removed by gcc 4.7. Outputs are as follow: $ g++-4.7 -m32 alignedassert.cpp ./a.out ctor 0xffdc58f0 copy 0x9f72008 copy 0x9f72018 copy 0x9f72028 copy 0x9f72038 copy 0x9f72048 ctor 0xffdc5900 g++-4.6 -m32 alignedassert.cpp ./a.out ctor 0xff8e19e0 copy 0x98e2008 a.out: alignedassert.cpp:18: Foo::Foo(const Foo): Assertion `(std::ptrdiff_t(array) % std::ptrdiff_t(16))==0' failed. Aborted
[Bug gcov-profile/53546] gcc ICEs when using -fripa at varpool.c:45
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53546 --- Comment #2 from asharif at gcc dot gnu.org 2012-07-10 11:43:31 UTC --- -fripa is the IPA optimizer in the google/* branches of gcc. It does lightweight IPO based on PGO/FDO.
[Bug bootstrap/53913] [4.8 regression] resource.c:1179:5: error: 'current_function_decl' undeclared broke m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53913 --- Comment #1 from Andreas Schwab schwab at gcc dot gnu.org 2012-07-10 11:48:07 UTC --- Author: schwab Date: Tue Jul 10 11:48:00 2012 New Revision: 189410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189410 Log: PR bootstrap/53913 * config/m68k/m68k.c (m68k_epilogue_uses): New. * config/m68k/m68k.h (EPILOGUE_USES): Use it. * config/m68k/m68k-protos.h (m68k_epilogue_uses): Add prototype. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k-protos.h trunk/gcc/config/m68k/m68k.c trunk/gcc/config/m68k/m68k.h
[Bug bootstrap/53913] [4.8 regression] resource.c:1179:5: error: 'current_function_decl' undeclared broke m68k bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53913 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-07-10 11:53:10 UTC --- Fixed.
[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 --- Comment #3 from asharif at gcc dot gnu.org 2012-07-10 12:00:21 UTC --- +cc: Jan Hubicka The use case here represents what happened as we were deploying for Chrome (the browser). Chrome is a moving source base and they did not want to integrate PGO into their build system. Doing so would require their nightly builders to run instrumented Chrome binaries on various devices (example, x86- and arm- based devices), get the PGO data and rebuild the optimized binary. Instead they wanted to generate PGO data offline and use it for slightly newer code. That way they could decouple the generation of PGO data from their build system. That is understandable because changing the build systems for large projects is a tedious task. Currently there are problems with offline PGO: 1. gcc can ICE in certain situations when the profile is out of date. 2. gcc thinks that the mismatched functions execute exactly 0 times and still considers the program summary of PGO to be valid (that includes run_max, sum_max, etc.). This misleads gcc into believing that the hot functions are cold (if they have mismatches). gcc should distinguish the case where the edge counts are truly 0, vs. the case where there is a profile mismatch. My patch addresses that. In general, I think PGO will get higher adoption if we make it resilient to slight changes in source code. That way developers can generate good PGO data independently of their nightly builds. Right now the situation is such that gcc's profile files have function ids with checksums instead of function names. If we add a single dummy function to the compilation unit, all the function ids are different and the entire profile file has checksum mismatches. My patch just addresses a part of the problem. If gcc uses function names instead of ids, gcc will be able to tolerate more source changes and I think PGO adoption will increase.
[Bug target/47066] HOST=i386-unknown-freebsd6.2, TARGET=arm--elf, cpu=arm7tdmi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47066 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 12:16:06 UTC --- This problem was specific to pre-eabi ports (and the way they failed to correctly tag some object files). Now these have been obsoleted, this is now a non-issue.
[Bug target/47091] non-elf arm targets fail to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47091 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target|arm-netbsd, arm-pe, |arm-netbsd |arm-wince-pe| --- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 12:25:01 UTC --- arm-pe and arm-wince-pe targets have now been removed from GCC.
[Bug target/53859] ICE when calculate insn latency for armv7e-m arch in O2 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859 gretay at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-10 CC||gretay at gcc dot gnu.org AssignedTo|unassigned at gcc dot |gretay at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from gretay at gcc dot gnu.org 2012-07-10 12:25:36 UTC --- Here is a patch that should fix it: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00380.html It would be great if you could try this patch in your setting and let me know if it solves the problem. Thank you, Greta
[Bug target/47088] arm-freebsd6 fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47088 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 12:27:25 UTC --- Arm-FreeBSD port was unmaintained and has been removed.
[Bug c++/53531] ,,,, accepted as template arguments for variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53531 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-07-10 12:58:25 UTC --- (In reply to comment #2) Jason, any idea which patch fixed these cases and if we need anything in the testsuite to prevent regressions before closing it? Nothing springs to mind. grep ,, variadic* doesn't get any hits, so adding a testcase wouldn't hurt.
[Bug c++/53531] ,,,, accepted as template arguments for variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53531 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-10 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-10 13:03:09 UTC --- OK, thanks, I'll do that. I tried reverting the patch for PR 47220 but that wasn't it, and I didn't look any further.
[Bug target/53914] New: poor code generated for offset addressing on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53914
Bug #: 53914
Summary: poor code generated for offset addressing on ppc32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
/* -m32 -O2 code for f5 thru f12 store y to a stack slot, load that to
a fpr, then store the fpr. The other function store y directly
from the input r5 and r6 as expected. */
void f1 (void *x, long long y) { *(long long *) (x + 32767) = y; }
void f2 (void *x, long long y) { *(long long *) (x + 32766) = y; }
void f3 (void *x, long long y) { *(long long *) (x + 32765) = y; }
void f4 (void *x, long long y) { *(long long *) (x + 32764) = y; }
void f5 (void *x, long long y) { *(long long *) (x + 32763) = y; }
void f6 (void *x, long long y) { *(long long *) (x + 32762) = y; }
void f7 (void *x, long long y) { *(long long *) (x + 32761) = y; }
void f8 (void *x, long long y) { *(long long *) (x + 32760) = y; }
void f9 (void *x, long long y) { *(long long *) (x + 32759) = y; }
void f10 (void *x, long long y) { *(long long *) (x + 32758) = y; }
void f11 (void *x, long long y) { *(long long *) (x + 32757) = y; }
void f12 (void *x, long long y) { *(long long *) (x + 32756) = y; }
void f13 (void *x, long long y) { *(long long *) (x + 32755) = y; }
void f14 (void *x, long long y) { *(long long *) (x + 32754) = y; }
void f15 (void *x, long long y) { *(long long *) (x + 32753) = y; }
void f16 (void *x, long long y) { *(long long *) (x + 32752) = y; }
void f17 (void *x, long long y) { *(long long *) (x + 32751) = y; }
void f18 (void *x, long long y) { *(long long *) (x + 32750) = y; }
void f19 (void *x, long long y) { *(long long *) (x + 32749) = y; }
void f20 (void *x, long long y) { *(long long *) (x + 32748) = y; }
[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail|| --- Comment #9 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 13:22:33 UTC --- Fixed in 4.6.0. 4.5 is no-longer being maintained.
[Bug gcov-profile/53915] New: gcov -f rounding problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915 Bug #: 53915 Summary: gcov -f rounding problem Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincent-...@vinc17.net I have the following problem with gcov 4.7.1 under Debian: ypig:/tmp/ompfr-gcov/src gcov -f round_prec.c Function 'mpfr_can_round_raw' Lines executed:100.00% of 44 Function 'mpfr_can_round' Lines executed:100.00% of 4 Function 'mpfr_prec_round' Lines executed:100.00% of 31 Function 'mpfr_round_raw_4' Lines executed:95.00% of 60 Function 'mpfr_round_raw_2' Lines executed:99.99% of 9 Function 'mpfr_round_raw' Lines executed:100.00% of 7 File 'round_prec.c' Lines executed:100.00% of 79 Creating 'round_prec.c.gcov' File 'round_raw_generic.c' Lines executed:97.37% of 76 Creating 'round_raw_generic.c.gcov' File '/usr/include/gmp-x86_64.h' No executable lines Removing 'gmp-x86_64.h.gcov' See the result for Function 'mpfr_round_raw_2': 99.99% of 9. This is not possible! Either all the lines are executed, in which case one should get 100%, or at most 8 lines of 9 are executed, in which case one should get 88.89% at most. This is reproducible on a Debian/unstable amd64 machine with MPFR trunk r8346 by running the tools/coverage script. I've also reported with bug on the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681076
[Bug target/53914] poor code generated for offset addressing on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53914 Alan Modra amodra at gmail dot com changed: What|Removed |Added Target||powerpc-linux --- Comment #1 from Alan Modra amodra at gmail dot com 2012-07-10 13:32:47 UTC --- Appears to be caused by o constraint in movdi_internal32 used for gpr-mem disallowing offsets larger than 32k-12 due to rs6000_mode_dependent_address. m is used for fpr-mem, so reload chooses a fpr.
[Bug target/53914] poor code generated for offset addressing on ppc32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53914 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-10 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug target/43047] internal compiler error: in extract_insn, at recog.c:2048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.8.0 --- Comment #14 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-10 14:14:52 UTC --- Wince support has been dropped in GCC-4.8
[Bug gcov-profile/53915] gcov -f rounding problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915 --- Comment #1 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-10 14:27:28 UTC --- The problem is probably in gcc/gcov.c, function format_gcov, which has: float ratio = bottom ? (float)top / bottom : 0; int ix; unsigned limit = 100; unsigned percent; for (ix = dp; ix--; ) limit *= 10; percent = (unsigned) (ratio * limit + (float)0.5); Using double instead of float would be a first improvement (2 occurrences in the first line, cast to be removed in the last line). Also, multiplying top by limit (after a cast to double) before dividing by bottom should be better, as the first operation (the multiplication) would be done exactly in practice. Something like that: percent = (unsigned) ((double) top * limit / bottom + 0.5); or even: percent = (unsigned) (((double) top * limit + (double) bottom / 2) / bottom);
[Bug gcov-profile/53915] gcov -f rounding problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915 --- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-10 14:46:28 UTC --- Actually this should not be the problem, because if top = bottom = 9, then the division is done exactly anyway; moreover percent = limit - 1; won't be executed in this case due to the condition top != bottom. Now, I can't explain the result.
[Bug gcov-profile/53915] gcov can call format_gcov with top bottom, which is unexpected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53915 Vincent Lefèvre vincent-gcc at vinc17 dot net changed: What|Removed |Added Summary|gcov -f rounding problem|gcov can call format_gcov ||with top bottom, which is ||unexpected Severity|minor |normal --- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-10 15:19:20 UTC --- After recompiling gcov with the -g option and testing with gdb: Function 'mpfr_round_raw_2' Breakpoint 1, format_gcov (top=10, bottom=9, dp=2) at ../../src/gcc/gcov.c:1651 and obviously the format_gcov function doesn't handle this case.
[Bug lto/53831] [4.7/4.8 Regression] Virtuals missing in LTO symtab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831 --- Comment #23 from Yuri Gribov tetra2005 at gmail dot com 2012-07-10 15:34:02 UTC --- The C++ Standard says that an inline function shall be defined in every translation unit in which it is used (n1905, 7.1.2). The test in question violates this rule: definition for C::f() is present only in impl.cpp. Should we consider the test invalid?
[Bug rtl-optimization/53916] New: [mips16] divide operation compiled result incorrect with GCC-4.6.3 '-O2' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53916 Bug #: 53916 Summary: [mips16] divide operation compiled result incorrect with GCC-4.6.3 '-O2' option Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: anmin_d...@yahoo.com.tw A simple C code with a simple divide operation to have incorrect compile result with '-O2' option (hence incorrect run time execution result). The very same C code compile result is OK with '-Os' option. I have not tested with other version of GCC, the compiler in question is a cross compiler GCC-4.6.3, target: mips-elf, host/build: i686-pc-cygwin. Here is the details... === full command line options = $ /cygdrive/c/Progra~1/vendor/tool-chain4/bin/mipsel-vendor-elf-gcc -mips16 -mips4 -msym32 -membedded-data -muninit-const-in-rodata -mcode-readable=pcrel -fno-common -msoft-float -EL -ansi -Wall -Wextra -G 0 -O2 -S afvals.c -o afvals.O2.S -v -save-temps === full console output messages = Using built-in specs. COLLECT_GCC=/cygdrive/c/Progra~1/vendor/tool-chain4/bin/mipsel-vendor-elf-gcc COLLECT_LTO_WRAPPER=/cygdrive/c/Progra~1/vendor/tool-chain4/libexec/gcc/mipsel-vendor-elf/4.6.3/lto-wrapper.exe Target: mipsel-vendor-elf Configured with: ../gcc-4.6.3/configure NEWLIB_CFLAGS=-D_R3000 LDFLAGS=--static --prefix='/cygdrive/c/Progra~1/vendor/tool-chain4' --target=mipsel-vendor-elf --build=i686-pc-cygwin --host=i686-pc-cygwin --with-sysroot='/cygdrive/c/Progra~1/vendor/tool-chain4' --with-gnu-as --with-gnu-ld --with-float=hard --disable-threads --with-stabs --disable-nls --disable-shared --with-newlib --without-headers --disable-biendian --with-divide=breaks --without-llsc --without-synci --disable-initfini-array --enable-version-specific-runtime-libs --enable-languages=c,c++ --disable-libssp --disable-libquadmath --disable-libgomp --disable-lto --disable-add-ons --enable-target-optspace --disable-profile --disable-nss-crypt --disable-nss --enable-cloog-backend=isl --with-host-libstdcxx=-Wl,-Bstatic,-lstdc++ Thread model: single gcc version 4.6.3 COLLECT_GCC_OPTIONS='-mips16' '-mips4' '-msym32' '-membedded-data' '-muninit-const-in-rodata' '-mcode-readable=pcrel' '-fno-common' '-msoft-float' '-EL' '-ansi' '-Wall' '-Wextra' '-G' '0' '-O2' '-S' '-o' 'afvals.O2.S' '-v' '-save-temps' '-mdivide-breaks' '-mno-llsc' '-mno-synci' /cygdrive/c/Progra~1/vendor/tool-chain4/libexec/gcc/mipsel-vendor-elf/4.6.3/cc1.exe -E -quiet -v -imultilib soft-float afvals.c -G 0 -mel -mips16 -mips4 -msym32 -membedded-data -muninit-const-in-rodata -mcode-readable=pcrel -msoft-float -mdivide-breaks -mno-llsc -mno-synci -ansi -Wall -Wextra -fno-common -O2 -fpch-preprocess -o afvals.i ignoring nonexistent directory /cygdrive/c/Progra~1/vendor/tool-chain4/usr/local/include ignoring nonexistent directory /cygdrive/c/Progra~1/vendor/tool-chain4/usr/include #include ... search starts here: #include ... search starts here: /cygdrive/c/Progra~1/vendor/tool-chain4/lib/gcc/mipsel-vendor-elf/4.6.3/include /cygdrive/c/Progra~1/vendor/tool-chain4/lib/gcc/mipsel-vendor-elf/4.6.3/include-fixed /cygdrive/c/Progra~1/vendor/tool-chain4/lib/gcc/mipsel-vendor-elf/4.6.3/../../../../mipsel-vendor-elf/include End of search list. COLLECT_GCC_OPTIONS='-mips16' '-mips4' '-msym32' '-membedded-data' '-muninit-const-in-rodata' '-mcode-readable=pcrel' '-fno-common' '-msoft-float' '-EL' '-ansi' '-Wall' '-Wextra' '-G' '0' '-O2' '-S' '-o' 'afvals.O2.S' '-v' '-save-temps' '-mdivide-breaks' '-mno-llsc' '-mno-synci' /cygdrive/c/Progra~1/vendor/tool-chain4/libexec/gcc/mipsel-vendor-elf/4.6.3/cc1.exe -fpreprocessed afvals.i -G 0 -mel -quiet -dumpbase afvals.c -mips16 -mips4 -msym32 -membedded-data -muninit-const-in-rodata -mcode-readable=pcrel -msoft-float -mdivide-breaks -mno-llsc -mno-synci -auxbase-strip afvals.O2.S -O2 -Wall -Wextra -ansi -version -fno-common -o afvals.O2.S GNU C version 4.6.3 (mipsel-vendor-elf) compiled by GNU C version 4.5.3, GMP version 5.0.4, MPFR version 3.1.0-p7, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C version 4.6.3 (mipsel-vendor-elf) compiled by GNU C version 4.5.3, GMP version 5.0.4, MPFR version 3.1.0-p7, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 301b4a641126d25934d363679c94e6be
[Bug middle-end/53917] New: Warning message line about variable points to place where variable doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917
Bug #: 53917
Summary: Warning message line about variable points to place
where variable doesn't occur
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 27771
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27771
Testcase
Hi,
I have noticed that when compiling the following test case (will attach to the
bug):
test1.c:
int a, b;
void fn1 ();
typedef enum
{
READ_WRITE
} TAG_STATE;
TAG_STATE fn2 ();
void
fn3 ()
{
int c;
if (a)
c = 0;
else
switch (fn2 ())
case 0:
c = 1;
b = c;
if (b)
fn1 ();
}
gcc says:
$ gcc -Os -S -Wall test1.c
test1.c: In function 'fn3':
test1.c:19:8: warning: 'c' may be used uninitialized in this function
[-Wuninitialized]
However line 19 is 'if (b)'.
Used gcc46 but also reproducible with gcc47.
[Bug middle-end/53917] Warning message line about variable points to place where variable doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917
--- Comment #1 from Paulo J. Matos Paulo.Matos at csr dot com 2012-07-10
16:37:20 UTC ---
Here's another example:
void fn1 ();
typedef struct
{
int hdr[0];
} foo;
typedef enum
{
READ_WRITE
} bar;
typedef struct
{
struct
{
foo t1;
} mp;
} foobar;
bar fn2 ();
typedef struct
{
foobar tag_mem_config;
} tag;
static int
fn3 (foobar * p1)
{
int valid;
if (p1-mp.t1.hdr[0])
valid = 0;
else
switch (fn2 ())
case 0:
valid = 1;
return valid;
}
void
fn4 ()
{
tag p_t1_rw_fsm_data;
if (fn3 (p_t1_rw_fsm_data.tag_mem_config))
fn1 ();
}
GCC says:
test.c: In function 'fn4':
test.c:38:8: warning: 'valid' may be used uninitialized in this function
[-Wuninitialized]
Again, line 38 is: if (fn3 (p_t1_rw_fsm_data.tag_mem_config))
In this case this looks like it's related to inlining.
[Bug other/53918] New: Incorrect version for cloog-ppl listed in prerequisites.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53918 Bug #: 53918 Summary: Incorrect version for cloog-ppl listed in prerequisites.html Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: schnet...@gmail.com The file INSTALL/prerequisites.html lists the file cloog-ppl-0.15.tar.gz as prerequisite. This is incorrect: (1) a file with this exact name does not exist at the location ftp://gcc.gnu.org/pub/gcc/infrastructure/ (2) e.g. the file cloog-ppl-0.15.9.tar.gz does not work, as it requires ppl-0.10, but the prerequisites explicitly require ppl-0.11 I believe that pointing to the file cloog-ppl-0.15.11.tar.gz instead would be correct.
[Bug middle-end/53917] Warning message line about variable points to place where variable doesn't occur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917 --- Comment #2 from Paulo J. Matos Paulo.Matos at csr dot com 2012-07-10 16:38:22 UTC --- Created attachment 27772 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27772 Another testcase (inlining issue)
[Bug rtl-optimization/53908] [4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-07-10 17:03:14 UTC --- (In reply to comment #2) I can't reproduce on x86_64-linux, Odd. What does valgrind say / did you check the generated code? HP: are you sure it fails on x86_64? Yes, as written. N.B.: I used --disable-bootstrap, but that shouldn't have any significance modulo bugs. Host (native) compiler was the mentioned Debian 4.4.5-8 x86_64 gcc, but not for all targets and only for pristine FSF code checks. Are you sure you used the gcc 4.7 branch for x86_64? ;) It can't be ruled out of course that there's some address hash thing clouding the issue, but the reproducibility seems stable (same gcc binary on different targets; different host gcc).
[Bug web/53919] New: Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 Bug #: 53919 Summary: Version-specific install instructions not available Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: schnet...@gmail.com The gcc web site does not seem to list version-specific install instructions. This is inconvenient, since e.g. prerequisites or other details may differ significantly between different versions. http://gcc.gnu.org/install/ shows install instructions, but these seem to pertain to the (unreleased) trunk. Unfortunately, this fact is not even mentioned. http://gcc.gnu.org/onlinedocs/ only has the manual, not the install instructions. The online install instructions should prominently mention that they are not valid for any released version, and that one should download the release and read those install instructions instead. Alternatively, the version-specific install instructions should be added next to the online manual.
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-10 17:41:19 UTC --- (In reply to comment #0) The online install instructions should prominently mention that they are not valid for any released version They generally are valid.
[Bug preprocessor/53920] New: gcc -E does not honor #pragma GCC diagnostic ignored -Wunused-macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 Bug #: 53920 Summary: gcc -E does not honor #pragma GCC diagnostic ignored -Wunused-macro Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: naes...@gmail.com iMac:gcc-bugs user$ cat cpp-pragma-GCC-diagnostic.c #pragma GCC diagnostic ignored -Wunused-macros #define FOO iMac:gcc-bugs user$ gcc-fsf-4.7 -Wunused-macros cpp-pragma-GCC-diagnostic.c -E # 1 cpp-pragma-GCC-diagnostic.c # 1 command-line # 1 cpp-pragma-GCC-diagnostic.c #pragma GCC diagnostic ignored -Wunused-macros cpp-pragma-GCC-diagnostic.c:3:0: warning: macro FOO is not used [-Wunused-macros] iMac:gcc-bugs 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.
[Bug target/53811] ICE: in insn_default_length, at config/i386/i386.md:529 (unrecognizable insn) with -mcmodel=large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811 --- Comment #9 from uros at gcc dot gnu.org 2012-07-10 17:53:53 UTC --- Author: uros Date: Tue Jul 10 17:53:48 2012 New Revision: 189412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189412 Log: Backport from mainline 2012-07-03 Uros Bizjak ubiz...@gmail.com PR target/53811 * config/i386/i386.c (x86_output_mi_thunk): Check if fnaddr satisfies sibcall_insn_operand. Move it to a temporary register if not. 2012-07-06 Uros Bizjak ubiz...@gmail.com PR target/53853 * config/i386/i386.c (x86_output_mi_thunk): For CM_LARGE_PIC model, emit PIC sequence for fnaddr symbol reference in advance. testsuite/ChangeLog: Backport from mainline 2012-07-03 Uros Bizjak ubiz...@gmail.com PR target/53811 * g++.dg/other/pr53811.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/other/pr53811.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/53853] FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853 --- Comment #7 from uros at gcc dot gnu.org 2012-07-10 17:53:56 UTC --- Author: uros Date: Tue Jul 10 17:53:48 2012 New Revision: 189412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189412 Log: Backport from mainline 2012-07-03 Uros Bizjak ubiz...@gmail.com PR target/53811 * config/i386/i386.c (x86_output_mi_thunk): Check if fnaddr satisfies sibcall_insn_operand. Move it to a temporary register if not. 2012-07-06 Uros Bizjak ubiz...@gmail.com PR target/53853 * config/i386/i386.c (x86_output_mi_thunk): For CM_LARGE_PIC model, emit PIC sequence for fnaddr symbol reference in advance. testsuite/ChangeLog: Backport from mainline 2012-07-03 Uros Bizjak ubiz...@gmail.com PR target/53811 * g++.dg/other/pr53811.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/other/pr53811.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/53811] ICE: in insn_default_length, at config/i386/i386.md:529 (unrecognizable insn) with -mcmodel=large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53811 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-07-10 17:56:05 UTC --- Fixed.
[Bug target/53853] FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-07-10 17:56:32 UTC --- Fixed.
[Bug preprocessor/50387] Doesn't process _Pragma when expanding a token sequence for #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50387 Samuel Bronson naesten at gmail dot com changed: What|Removed |Added CC||naesten at gmail dot com --- Comment #1 from Samuel Bronson naesten at gmail dot com 2012-07-10 18:18:20 UTC --- I think you forgot the GCC at the beginning of the pragma text? Also, you forgot to show what happens when you attempt to do this, preferably using a test header constructed for the purpose (to keep the testcase small and self-contained). But perhaps adding GCC is all you need?
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #2 from Erik Schnetter schnetter at gmail dot com 2012-07-10 18:26:53 UTC --- I am currently installing gcc 4.7.1, and and dealing with the prerequisites. gmp 5.x was not recognised as valid version; I had to install gmp 4.x instead. Finding a valid combination of ppl/cloog/isl versions was another issue: after downloading and installing isl, I found that gcc 4.7.1 doesn't even offer the respective configuration option. These may just be details in the prerequisites, but it is just these details that I am looking for in the install instructions. I appreciate that the instructions generally don't change that much between versions, but the same can probably be said about the manual -- new options, new optimisations, and new architectures tend to be few among a large bulk of things that remain the same. Yet, the web site makes a clear distinctions between manuals for different versions, and doesn't even seem to offer an online manual for the trunk.
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-10 18:36:34 UTC --- (In reply to comment #2) between manuals for different versions, and doesn't even seem to offer an online manual for the trunk. Yes it does, at the bottom of the page: http://gcc.gnu.org/onlinedocs/
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-10 18:45:54 UTC --- ... and I was using gmp 5.0.1 with gcc 4.6 over a year ago: http://advogato.org/person/redi/diary/240.html If it doesn't work with 4.7 you did something wrong, it's not a problem with the install docs. The isl configury has just changed, so that might be invalid for anything but trunk.
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #5 from Erik Schnetter schnetter at gmail dot com 2012-07-10 19:05:01 UTC --- Yes, the isl changes are part of what I mean. Since the version-specific install instructions are already there, they may as well be available on the web, and/or the web could warn about such possible differences.
[Bug preprocessor/53920] gcc -E does not honor #pragma GCC diagnostic ignored -Wunused-macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 --- Comment #1 from Samuel Bronson naesten at gmail dot com 2012-07-10 19:07:26 UTC --- Oh, I suppose I should mention that I ran into this because I was using ccache to compile Emacs with --enable-gcc-warnings, and by default ccache runs the preprocessor and the compiler in separate passes (so that it can skip the compilation proper if it has cached output for a given preprocessor output), and then pastes together the diagnostic output from the two passes. (Thankfully, setting the environment variable CCACHE_CPP2 causes ccache to throw out the preprocessor output after hashing, which is a quite effective workaround for this sort of thing, though preprocessing the source twice does make things a bit slower on cache misses.)
[Bug rtl-optimization/53908] [4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-07-10 19:55:25 UTC --- My mistake, I can now reproduce the runtime SEGV on x86_64-linux with vanilla gcc-4.7-20120707.
[Bug target/53911] [SH] Improve displacement addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53911 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-10 22:01:53 UTC --- Author: olegendo Date: Tue Jul 10 22:01:44 2012 New Revision: 189416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189416 Log: PR target/53911 * config/sh/sh.md: Remove displacement addresssing related splits. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug target/53886] Seg fault in sh_insn_length_adjustment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886 --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-10 22:07:36 UTC --- Author: olegendo Date: Tue Jul 10 22:07:29 2012 New Revision: 189417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189417 Log: PR target/53886 * gcc.c-torture/compile/pr53886.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr53886.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/53886] Seg fault in sh_insn_length_adjustment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-10 22:12:08 UTC --- Should be OK now.
[Bug rtl-optimization/53908] [4.6/4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-07-10 22:50:24 UTC --- On x86_64-linux the SEGV went away on trunk with r186159: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00108.html http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00202.html The patch description makes it sound more like a cleanup than fixing actual bugs, but when I diff the assembly code for the test case with r186158 and r186159 I see: --- pr53908.s-r186158 2012-07-11 00:28:57.0 +0200 +++ pr53908.s-r186159 2012-07-11 00:34:32.0 +0200 ... callis_basic testl %eax, %eax - movq8(%rsp), %rbp - js .L68 -.L29: + js .L29 +.L33: movqusers(%rip), %rbx + movq8(%rsp), %rbp testq %rbx, %rbx ... That is, a load is being moved across a control flow insn. All other diffs seem to just be changed label numbers. I'll give it some more testing tomorrow.
[Bug target/53859] ICE when calculate insn latency for armv7e-m arch in O2 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859 zhuolin liu zhuolin.liu at arm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from zhuolin liu zhuolin.liu at arm dot com 2012-07-11 01:03:38 UTC --- Thanks.The patch worked.
[Bug c++/53921] New: [C++0x] ICE on lambda inside method of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53921
Bug #: 53921
Summary: [C++0x] ICE on lambda inside method of class template
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: philip.pro...@gmail.com
$ g++ -std=c++0x -Wall -Wextra bug.cpp
bug.cpp: In lambda function:
bug.cpp:6:34: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
g++ --version
g++ (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.
void bar(int) { }
template class X
struct B {
void foo() {
auto c = [this]() { bar(value); };
}
int value;
};
Additional info: not reproducible using gcc 4.6.2. Successfully compiles if you
access 'value' using 'this' (this-value).
