[Bug sanitizer/56535] ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56535 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2013-03-16 08:04:07 UTC --- Also happens during --with-build-config=bootstrap-asan and profiledbootstrap with -enable-languages=c,c++: /var/tmp/gcc_build_dir/./prev-gcc/xg++ -B/var/tmp/gcc_build_dir/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/markus/gcc/libstdc++-v3/libsupc++ -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -march=native -O3 -pipe -fsanitize=address -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/markus/gcc/gcc -I/home/markus/gcc/gcc/build -I/home/markus/gcc/gcc/../include -I/home/markus/gcc/gcc/../libcpp/include -I/home/markus/gcc/gcc/../libdecnumber -I/home/markus/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/markus/gcc/gcc/../libbacktrace -o build/genmodes.o /home/markus/gcc/gcc/genmodes.c /home/markus/gcc/gcc/genmodes.c: In function ‘void _ZL18make_complex_modes10mode_classPKcj.constprop.2(mode_class, unsigned int)’: /home/markus/gcc/gcc/genmodes.c:423:1: internal compiler error: in build2_stat, at tree.c:3885 make_complex_modes (enum mode_class cl, ^
[Bug sanitizer/56628] bootstrap-lto bootstrap-asan / profiledbootstrap fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56628 --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2013-03-16 08:08:09 UTC --- The bootstrap-asan/profiledbootstrap issue looks like dup of Bug 56535. And please ignore my remark about the huge size of SZ.
[Bug sanitizer/56630] New: gcc's address-sanitizer uses 75% more memory than clang's on simple testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56630 Bug #: 56630 Summary: gcc's address-sanitizer uses 75% more memory than clang's on simple testcase Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org markus@x4 ~ % c++ -O2 -fsanitize=address bench.cpp markus@x4 ~ % time ./a.out ... ./a.out 61.65s user 1.10s system 100% cpu 1:02.75 total UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD markus3810 22602 99 4563582920 3183864 1 09:15 pts/12 00:01:02 ./a.out markus@x4 ~ % clang++ -O2 -fsanitize=address bench.cpp markus@x4 ~ % time ./a.out ... ./a.out 64.04s user 0.29s system 100% cpu 1:04.31 total UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD markus3722 22602 99 4295159814 784236 0 09:13 pts/12 00:01:01 ./a.out
[Bug sanitizer/56630] gcc's address-sanitizer uses 75% more memory than clang's on simple testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56630 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2013-03-16 08:24:56 UTC --- Created attachment 29676 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29676 simple c++ std. container benchmark
[Bug target/56110] Sub-optimal code: unnecessary CMP after AND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56110 --- Comment #2 from Tilman Sauerbeck til...@code-monkey.de 2013-03-16 09:01:17 UTC --- Created attachment 29677 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29677 WIP patch I'm not really sure if this patch is good or bad. The discussion on the ML died off eventually (maybe because I asked one too many silly questions). Anyway, without guidance I won't be able to finish this, but I want to post my WIP here at least.
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-16 09:40:02 UTC --- I agree. And we discussed it already somewhere.
[Bug c++/56629] template struct confused with template member function of same name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56629 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-16 09:45:38 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55576 ***
[Bug c++/55576] Fails to compile a call to template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||talljimbo at gmail dot com --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-16 09:45:38 UTC --- *** Bug 56629 has been marked as a duplicate of this bug. ***
[Bug c++/56582] ICE on negative array index in C++11 constant expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56582 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-16 10:02:21 UTC --- Author: paolo Date: Sat Mar 16 10:02:11 2013 New Revision: 196701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196701 Log: /cp 2013-03-16 Paolo Carlini paolo.carl...@oracle.com PR c++/56582 * semantics.c (cxx_eval_array_reference): Check for negative index. /testsuite 2013-03-16 Paolo Carlini paolo.carl...@oracle.com PR c++/56582 * g++.dg/cpp0x/constexpr-array5.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/56582] ICE on negative array index in C++11 constant expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56582 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.8.1
[Bug sanitizer/56630] gcc's address-sanitizer uses 75% more memory than clang's on simple testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56630 --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2013-03-16 10:30:51 UTC --- Looks like the sorting of a std::list container is mostly responsible: 168 listelement_t container(first, last); 169 container.sort(); When I run just with size 10 I get: markus@x4 ~ % c++ -O2 -fsanitize=address bench.cpp markus@x4 ~ % time ./mem ./a.out sizearray vector with pointersvector with iterators deque 10 0.470.480.541.06 listset multiset 13.69(!)2.413.97 ./mem ./a.out 21.80s user 0.99s system 99% cpu 22.791 total peak=2736348 Without the list test I get a reasonable result: (238 //run(list_test, buffer, buffer_end, n);) markus@x4 ~ % time ./mem ./a.out sizearray vector with pointersvector with iterators 10 0.460.470.5 deque set multiset 1.031.933.71 ./mem ./a.out 7.67s user 0.56s system 99% cpu 8.245 total markus@x4 ~ % memusg: peak=1415416 For comparison clang: markus@x4 ~ % clang++ -O2 -fsanitize=address bench.cpp markus@x4 ~ % time ./mem ./a.out sizearray vector with pointersvector with iterators deque 10 0.420.410.42 0.96 list set multiset 5.732.935.69 ./mem ./a.out 16.52s user 0.10s system 99% cpu 16.627 total markus@x4 ~ % memusg: peak=229660
GCC needlessly saves Global Register Variables
I use Microchip's C30 compiler which, for all appearances, including Microchip's statements, is derived from the GCC. It does us the ld linker. Although, Microchip refuses to address my issue because they say that the following is a GCC issue. Using this syntax, I declare a global register variable pointer PntrC. register Cavity_t *PntrC asm(w13); // Global cavity pointer So my question is, why does GCC bother to copy the globally declared w13 register into another register and then use that register as a pointer when w13 would have worked just fine. Over the length of my program, GCC has wasted 204 words of flash needlessly copying w13. Here are five examples out of the 204 total. D:\ES1030\Firmware\V-1.45_RCH\Subs.c:67036: 149CE 78040D mov.w w13,w8 D:\ES1030\Firmware\V-1.45_RCH\Subs.c:67209: 14A66 78018D mov.w w13,w3 D:\ES1030\Firmware\V-1.45_RCH\Subs.c:70555: 0536C 78008D mov.w w13,w1 D:\ES1030\Firmware\V-1.45_RCH\Subs.c:70726: 0542E 78010D mov.w w13,w2 D:\ES1030\Firmware\V-1.45_RCH\Subs.c:74011: 09258 78050D mov.w w13,w10 Search complete. 204 matches found. Here is an example: 426: PntrC-Cavity_TempFP = PntrC-Cavity_TempFP * 1.8 + 32.0;// Convert temperature to Fahrenheit 087F8 78040D mov.w w13,w8 087FA 22 mov.w #0x,w2 087FC 23FE63 mov.w #0x3fe6,w3 087FE 90A86D mov.w [w13+220],w0 08800 90A8FD mov.w [w13+222],w1 08802 071EED rcall __mulsf3 08804 22 mov.w #0x0,w2 08806 242003 mov.w #0x4200,w3 08808 071F79 rcall __addsf3 0880A 98AC60 mov.w w0,[w8+220] 0880C 98AC71 mov.w w1,[w8+222] 427: PntrAG-Data = (t_u16)PntrC-Cavity_TempFP; // Create the integer cavity temperature input 0880E 809EC9 mov.w PntrAG,w9 08810 78040D mov.w w13,w8 08812 90A86D mov.w [w13+220],w0 08814 90A8FD mov.w [w13+222],w1 08816 071DDC rcall __fixunssfsi 08818 780100 mov.w w0,w2 0881A 780C80 mov.w w0,[w9] 428: if (PntrC-Prb_Res_Avg_Cntr PROBE_AVG_DVSR) // If the capture averager pipeline is not yet full 0881C 90A888 mov.w [w8+208],w1 0881E 200630 mov.w #0x63,w0 08820 508F80 sub.w w1,w0,[w15] 08822 3E0006 bra gtu, 0x008830 In the above code, GCC copies w13 to w8. Then it uses w13 as a pointer, as it should, until some math library calls, then it uses w8 for a while. Then GCC does it all again, another copy of w13 to w8, point with w13, then point with w8. Why??? One might say that GCC is afraid that the library routines might corrupt w13. But if that were the case, GCC should eventually copy w8 back to w13. This never happens. The only writes to w13 in the entire program are where my C code purposefully sets the cavity pointer w13. Since I only have about 150 words of flash left in the chip, I would dearly love to get back the 204 words needlessly used to save the global register variable w13. Is there a way to command GCC to always use the global register declared w13 pointer directly, without wasting resources needlessly copying it to other registers? Wouldn't you call this a bug? The driving idea behind global register variables is to create highly efficient machine code, not waste 0.5% of someone's 44,000 words of precious flash memory needlessly. -- View this message in context: http://gcc.1065356.n5.nabble.com/GCC-needlessly-saves-Global-Register-Variables-tp921866.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug other/56631] New: duplicated sse code in switch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56631 Bug #: 56631 Summary: duplicated sse code in switch Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: nel...@seznam.cz Consider attached testcase. When compiled with -Os,-O2,-O3 it duplicates zeroing xmm1 register across all branches. Moving zeroing before braches will save space. Relevant assembly at -Os is jmp *.L19(,%rax,8) .section .rodata .align 8 .align 4 .L19: .quad .L21 .quad .L4 .quad .L5 snip .L21: xorps %xmm1, %xmm1 .L38: movaps %xmm0, %xmm2 pcmpeqb %xmm1, %xmm2 pmovmskb %xmm2, %eax testl %eax, %eax jne .L1 .L2: movdqu %xmm0, (%rdi) addq $64, %rdi movups 64(%rsi), %xmm0 addq $64, %rsi jmp .L38 .L4: xorps %xmm1, %xmm1 incq %rdi .L23: snip .L5: xorps %xmm1, %xmm1 addq $2, %rdi
[Bug other/56631] duplicated sse code in switch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56631 --- Comment #1 from Ondrej Bilka neleai at seznam dot cz 2013-03-16 11:36:04 UTC --- Created attachment 29678 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29678 testcase
[Bug sanitizer/56535] ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56535 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-16 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-16 11:38:40 UTC --- Following comment #1, marked as NEW.
[Bug c/56600] loop goes indefinite when non-loop integer variable overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56600 Chung-Ju Wu jasonwucj at gmail dot com changed: What|Removed |Added CC||jasonwucj at gmail dot com --- Comment #3 from Chung-Ju Wu jasonwucj at gmail dot com 2013-03-16 11:44:03 UTC --- (In reply to comment #1) Integer overflow is causing undefined behaviour. If you want wraparound semantics either use unsigned int or -fwrapv. Hi, Hyun-Ho Kyeong, More information about such undefined behavior~ :) According to C99 standard: C99 6.3.1.4 Point 1: ... If the value of the integral part cannot be represented by the integer type, the behavior is undefined. C99 6.5 Point 5: ... if the result is ... not in the range of representable values for its type... the behavior is undefined.
[Bug c++/56632] New: [C++0x] call mem func from lambda with captured this - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56632
Bug #: 56632
Summary: [C++0x] call mem func from lambda with captured this
- internal compiler error
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: allocato...@gmail.com
Created attachment 29679
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29679
call member func from lambda from another func
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
g++ -std=c++11 bug.cpp
bug.cpp: In lambda function:
bug.cpp:16:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
it's normal compile and work, if I change
[this]() { f(); }();
to
[this]() { this-f(); }();
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #6 from ahansson andreas.hansson at gmail dot com 2013-03-16 12:01:39 UTC --- (In reply to comment #4) I'm happy to fix things in libstdc++ that are broken and cause real problems for clang users, but this is correct C++ and causes a spurious warning. Not a bug, not worth wasting time on. The potential for real problems was my main reason for pointing it out. I ran some (unrelated) tests on Fedora Rawhide (fc19) with clang 3.2 RELEASE and gcc 4.8.0 and this issue popped up as -Wall -Werror was used for the project in question. The two lines mentioned are the only issues encountered. If it is worth fixing or not I leave up to you to decide, I merely wanted to highlight the potential issues.
[Bug c++/56632] [C++0x] call mem func from lambda with captured this - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56632 --- Comment #1 from galuza allocator64 at gmail dot com 2013-03-16 12:18:40 UTC --- This bug is only in template class
[Bug c++/56632] [C++0x] call mem func from lambda with captured this - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56632 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.3, 4.8.0 Resolution||FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-16 12:47:36 UTC --- This is already fixed for 4.7.3.
[Bug c++/56632] [C++0x] call mem func from lambda with captured this - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56632 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-16 13:04:11 UTC --- *** This bug has been marked as a duplicate of bug 53137 ***
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||allocator64 at gmail dot ||com --- Comment #24 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-16 13:04:11 UTC --- *** Bug 56632 has been marked as a duplicate of this bug. ***
[Bug middle-end/55943] [4.6/4.7/4.8/4.9 Regression] ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target|ia64-*-*|ia64-*-*,hppa*64*-*-* CC||danglin at gcc dot gnu.org --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2013-03-16 13:17:17 UTC --- I believe the problem is in this hunk of code: /* See if we can coerce the target into moving both values at once. */ /* Move floating point as parts. */ if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT can_create_pseudo_p () optab_handler (mov_optab, GET_MODE_INNER (mode)) != CODE_FOR_nothing) try_int = false; /* Not possible if the values are inherently not adjacent. */ else if (GET_CODE (x) == CONCAT || GET_CODE (y) == CONCAT) try_int = false; /* Is possible if both are registers (or subregs of registers). */ else if (register_operand (x, mode) register_operand (y, mode)) try_int = true; /* If one of the operands is a memory, and alignment constraints are friendly enough, we may be able to do combined memory operations. We do not attempt this if Y is a constant because that combination is usually better with the by-parts thing below. */ else if ((MEM_P (x) ? !CONSTANT_P (y) : MEM_P (y)) (!STRICT_ALIGNMENT || get_mode_alignment (mode) == BIGGEST_ALIGNMENT)) try_int = true; else try_int = false; When the inner mode is smaller than a word, a pseudo is needed to extract the value. The asm causes this to occur after reload starts, causing the ICE.
[Bug middle-end/55943] [4.6/4.7/4.8/4.9 Regression] ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2013-03-16 13:19:46 UTC --- Created attachment 29680 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29680 Patch Oops, previous comment comment contained patch that I'm testing.
[Bug c/56569] When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hp at gcc dot gnu.org Version|3.4.0 |3.1.2 Resolution||FIXED Target Milestone|--- |4.4.0 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2013-03-16 13:20:38 UTC --- There is no release named gcc-4.3.43 so when closing the report I wrote 4.4.0 as the target milestone. (Please adjust to a 4.3 release.)
[Bug c++/56633] New: Overload selection error for non-static data member initialization with initializer list in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56633
Bug #: 56633
Summary: Overload selection error for non-static data member
initialization with initializer list in template class
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@quanttec.com
g++ (the current SVN version) fails to compile the following valid c++11 code
#include atomic
struct Test1 {
std::atomicint value2{0}; // no problem here
};
template typename T // T is not used
struct Test2 {
std::atomicint value2{0}; // fails to compile
};
int main() {
Test1 test;
Test2int test2;
return 0;
}
The following error message is generated for Test2:
g++ --std=c++11 test.cpp
test.cpp: In constructor ‘constexpr Test2int::Test2()’:
test.cpp:8:8: error: use of deleted function ‘std::atomicint::atomic(const
std::atomicint)’
struct Test2 {
^
In file included from test.cpp:1:0:
/opt/gcc/include/c++/4.8.0/atomic:601:7: error: declared here
atomic(const atomic) = delete;
^
test.cpp: In function ‘int main()’:
test.cpp:14:16: note: synthesized method ‘constexpr Test2int::Test2()’ first
required here
Test2int test2;
[Bug libgcc/56634] New: libgcc does not compile for 4.7.2: Yields internal compiler error: Bus error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56634 Bug #: 56634 Summary: libgcc does not compile for 4.7.2: Yields internal compiler error: Bus error Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcc AssignedTo: unassig...@gcc.gnu.org ReportedBy: basi...@udc.es Created attachment 29681 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29681 preprocessed file generated by adding -save-temps I was compiling the distribution for gcc 4.7.2 and broke with: /tmp/obj/./gcc/xgcc -B/tmp/obj/./gcc/ -B/usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/bin/ -B/usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/lib/ -isystem /usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/include -isystem /usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/sys-include-g -O2 -m64 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -Wa,-force_cpusubtype_ALL -mmacosx-version-min=10.4 -fno-common -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -pipe -Wa,-force_cpusubtype_ALL -mmacosx-version-min=10.4 -fno-common -mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcc-4.7.2/libgcc -I../../../../gcc-4.7.2/libgcc/. -I../../../../gcc-4.7.2/libgcc/../gcc -I../../../../gcc-4.7.2/libgcc/../include -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-4.7.2/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc-4.7.2/libgcc/libgcc2.c: In function '__multi3': ../../../../gcc-4.7.2/libgcc/libgcc2.c:549:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- The output obtained when flags -v -savetemps are added to the command line is: xgcc: warning: -pipe ignored because -save-temps specified Reading specs from /tmp/obj/./gcc/specs COLLECT_GCC=/tmp/obj/./gcc/xgcc Target: powerpc-apple-darwin9.8.0 Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gcc-4.72 --enable-languages=c,c++,fortran --disable-nls Thread model: posix gcc version 4.7.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B' '/tmp/obj/./gcc/' '-B' '/usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/bin/' '-B' '/usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/lib/' '-isystem' '/usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/include' '-isystem' '/usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/sys-include' '-g' '-O2' '-m64' '-O2' '-g' '-O2' '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wwrite-strings' '-Wcast-qual' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' '-pipe' '-mmacosx-version-min=10.4' '-mlong-double-128' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' '-fno-stack-protector' '-pipe' '-mmacosx-version-min=10.4' '-fno-common' '-mlong-double-128' '-I' '.' '-I' '.' '-I' '../../.././gcc' '-I' '../../../../gcc-4.7.2/libgcc' '-I' '../../../../gcc-4.7.2/libgcc/.' '-I' '../../../../gcc-4.7.2/libgcc/../gcc' '-I' '../../../../gcc-4.7.2/libgcc/../include' '-D' 'USE_EMUTLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=hidden' '-D' 'HIDE_EXPORTS' /tmp/obj/./gcc/cc1 -E -quiet -v -I . -I . -I ../../.././gcc -I ../../../../gcc-4.7.2/libgcc -I ../../../../gcc-4.7.2/libgcc/. -I ../../../../gcc-4.7.2/libgcc/../gcc -I ../../../../gcc-4.7.2/libgcc/../include -imultilib ppc64 -iprefix /private/tmp/obj/gcc/../lib/gcc/powerpc-apple-darwin9.8.0/4.7.2/ -isystem /tmp/obj/./gcc/include -isystem /tmp/obj/./gcc/include-fixed -MD _muldi3.d -MF _muldi3.dep -MP -MT _muldi3.o -D__DYNAMIC__ -D IN_GCC -D IN_LIBGCC2 -D USE_EMUTLS -D L_muldi3 -D HIDE_EXPORTS -isystem /usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/include -isystem /usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/sys-include -isystem ./include ../../../../gcc-4.7.2/libgcc/libgcc2.c -feliminate-unused-debug-symbols -fPIC -m64 -mmacosx-version-min=10.4 -mlong-double-128 -mmacosx-version-min=10.4 -mlong-double-128 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fbuilding-libgcc -fno-stack-protector -fno-common -fvisibility=hidden -g -g -g -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory /usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/include ignoring nonexistent directory /usr/local/gcc-4.72/powerpc-apple-darwin9.8.0/sys-include ignoring nonexistent directory ./include ignoring nonexistent directory /private/tmp/obj/gcc/../lib/gcc/powerpc-apple-darwin9.8.0/4.7.2/include ignoring nonexistent directory
[Bug c/56635] New: [4.8 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635 Bug #: 56635 Summary: [4.8 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: or...@cora.nwra.com In file included from /builddir/build/BUILD/gdl-0.9.3/src/datatypes.cpp:67:0: /builddir/build/BUILD/gdl-0.9.3/src/basic_op.cpp: In function 'built-in': /builddir/build/BUILD/gdl-0.9.3/src/basic_op.cpp:3791:9: internal compiler error: in find_lattice_value, at tree-complex.c:151 #pragma omp parallel if (nEl = CpuTPOOL_MIN_ELTS (CpuTPOOL_MAX_ELTS == 0 || CpuTPOOL_MAX_ELTS = nEl)) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccXWRPxa.out file, please attach this to your bugreport. gcc-4.8.0-0.16.fc19.x86_64
[Bug c/56635] [4.8 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-16 16:19:56 UTC --- Preprocessed source stored into /tmp/ccXWRPxa.out file, please attach this to your bugreport.
[Bug c++/56636] New: strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636
Bug #: 56636
Summary: strange interaction of dynamic_cast and unique_ptr
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-b...@naturalcleaningcalgary.com
The following program produces a segfault at the dynamic_cast. If I change
std::unique_ptrint to int*, or if I drop the dynamic_cast, the segfault goes
away.
#include memory
struct A
{
void F() const
{
F_impl();
}
virtual std::unique_ptrint F_impl() const = 0;
};
template typename Derived
struct A_impl : virtual A
{
std::unique_ptrint F_impl() const override
{
dynamic_castconst Derived (*this);
return nullptr;
}
};
struct B : virtual A {};
struct C : B, A_implC {};
int main()
{
C().F();
}
$ g++ -std=c++11 -otest test.cpp ./test.exe
I am using GCC 4.7.2 under MinGW, configured with --enable-libstdcxx-debug
--enable-languages=c,c++ --build=pentium4-pc-mingw32 --disable-nls
--disable-win32-registry --enable-threads.
(gdb) run
Starting program: c:\devel\page\build/test.exe
[New Thread 2356.0xa10]
Program received signal SIGSEGV, Segmentation fault.
__cxxabiv1::__dynamic_cast (src_ptr=0x4031f4, src_type=0x403180,
dst_type=0x403160, src2dst=4)
at ../../../../gcc-4.7.2/libstdc++-v3/libsupc++/dyncast.cc:56
56adjust_pointer void (src_ptr, prefix-whole_object);
(gdb) bt
#0 __cxxabiv1::__dynamic_cast (src_ptr=0x4031f4, src_type=0x403180,
dst_type=0x403160, src2dst=4)
at ../../../../gcc-4.7.2/libstdc++-v3/libsupc++/dyncast.cc:56
#1 0x00401d04 in A_implC::F_impl() const ()
#2 0x00401cc6 in A::F() const ()
#3 0x00401378 in main ()
[Bug fortran/56637] New: Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 Bug #: 56637 Summary: Bad result on max(1,shiftr(j,1)) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 17:39:54 UTC --- Must be a target issue, it works fine on x86_64-linux
[Bug c++/56633] Overload selection error for non-static data member initialization with initializer list in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56633
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-03-16
CC||jason at gcc dot gnu.org
Ever Confirmed|0 |1
Known to fail||4.7.3
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16
17:45:07 UTC ---
Confirmed
struct A {
A(int) { }
A(const A) = delete;
};
struct Test1 {
A value2{0}; // no problem here
};
template typename T // T is not used
struct Test2 {
A value2{0}; // fails to compile
};
int main() {
Test1 test;
Test2int test2;
return 0;
}
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #1 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 18:02:49 UTC --- I realize this is not much help for a bug report. I can't get a small test case to fail, and if I change the optimization level it works. Also, I can't be sure whether the problem is in the compiler or the library, but I suspect the former. Here is a small snippet of code k = max(1, shiftr(j,1)) ! The increment during the sort do ! Sort constraints to make active (Shell sort) do i = k + 1, j In my small test case j is 13. And k gets the value 1. If I precede the first statement with a garbage statement i2=17 then after the first statement above, k has the correct value of 6, even though the added statement should not have changed the result. Here are my flags -ggdb -march=native -mpc80 -funroll-loops -pipe \ -ftree-vectorize -floop-strip-mine \ -floop-block -fimplicit-none -finit-real=NAN -fopenmp\ -fcheck=bounds -Wall -Wextra If I follow -ggdb with either -O1 or -O2 it gets the correct result. This is running on a Gentoo Linux system, with Intel I7 CPU's. Finally, here is a dump of the assembler code from the start of the first statement. Dump of assembler code from 0x40e5f1 to 0x40e6f1: = 0x0040e5f1 find_unequals+5571: mov0x1204(%rbx),%edx 0x0040e5f7 find_unequals+5577: mov$0x1,%eax 0x0040e5fc find_unequals+5582: shr%edx 0x0040e5fe find_unequals+5584: cmp%eax,%edx 0x0040e600 find_unequals+5586: jle0x40e604 find_unequals+5590 0x0040e602 find_unequals+5588: mov%edx,%eax 0x0040e604 find_unequals+5590: mov%eax,0x1330(%rbx) 0x0040e60a find_unequals+5596: mov0x1330(%rbx),%eax 0x0040e610 find_unequals+5602: add$0x1,%eax 0x0040e613 find_unequals+5605: mov0x1204(%rbx),%esi 0x0040e619 find_unequals+5611: mov%eax,0x133c(%rbx) 0x0040e61f find_unequals+5617: mov0x133c(%rbx),%eax 0x0040e625 find_unequals+5623: cmp%esi,%eax 0x0040e627 find_unequals+5625: jg 0x40ea50 find_unequals+6690 0x0040e62d find_unequals+5631: jmp0x40e630 find_unequals+5634 0x0040e62f find_unequals+5633: nop 0x0040e630 find_unequals+5634: mov0x133c(%rbx),%eax 0x0040e636 find_unequals+5640: cltq 0x0040e638 find_unequals+5642: test %rax,%rax 0x0040e63b find_unequals+5645: setle %dl 0x0040e63e find_unequals+5648: movzbl %dl,%edx 0x0040e641 find_unequals+5651: mov%edx,%edx 0x0040e643 find_unequals+5653: and$0x1,%edx 0x0040e646 find_unequals+5656: test %edx,%edx 0x0040e648 find_unequals+5658: je 0x40e666 find_unequals+5688 0x0040e64a find_unequals+5660: mov$0x1,%ecx 0x0040e64f find_unequals+5665: mov%rax,%rdx 0x0040e652 find_unequals+5668: mov$0x4820d8,%esi 0x0040e657 find_unequals+5673: mov$0x4827f0,%edi 0x0040e65c find_unequals+5678: mov$0x0,%eax 0x0040e661 find_unequals+5683: callq 0x401d70 _gfortran_runtime_error_at@plt 0x0040e666 find_unequals+5688: cmp$0x12,%rax 0x0040e66a find_unequals+5692: setg %dl 0x0040e66d find_unequals+5695: movzbl %dl,%edx 0x0040e670 find_unequals+5698: mov%edx,%edx 0x0040e672 find_unequals+5700: and$0x1,%edx 0x0040e675 find_unequals+5703: test %edx,%edx 0x0040e677 find_unequals+5705: je 0x40e695 find_unequals+5735 0x0040e679 find_unequals+5707: mov$0x12,%ecx 0x0040e67e find_unequals+5712: mov%rax,%rdx 0x0040e681 find_unequals+5715: mov$0x482148,%esi 0x0040e686 find_unequals+5720: mov$0x4827f0,%edi 0x0040e68b find_unequals+5725: mov$0x0,%eax 0x0040e690 find_unequals+5730: callq 0x401d70 _gfortran_runtime_error_at@plt 0x0040e695 find_unequals+5735: sub$0x1,%rax 0x0040e699 find_unequals+5739: add$0x4b8,%rax 0x0040e69f find_unequals+5745: mov0x4(%rbx,%rax,4),%eax 0x0040e6a3 find_unequals+5749: mov%eax,0x1200(%rbx) 0x0040e6a9 find_unequals+5755: mov0x1200(%rbx),%eax 0x0040e6af find_unequals+5761: add$0x1,%eax 0x0040e6b2 find_unequals+5764: movslq %eax,%rdx 0x0040e6b5 find_unequals+5767: test %rdx,%rdx 0x0040e6b8 find_unequals+5770: setle %al 0x0040e6bb find_unequals+5773: movzbl %al,%eax
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-16 18:16:10 UTC --- What happens if you don't use the graphite options '-floop-strip-mine -floop-block'? How big is your small test case and on which libraries does it depends?
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #3 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 18:46:06 UTC --- First some confusion. If I single step over the first statement it works properly. Once past that confusion, deleting both -floop-block and -floop-strip-mine from the make file it still fails. Although the test case I'm running is small, the actual code is quite large. After realizing the problem with single stepping over the statement causing it to work, I just tried that with the extra statement in front, and that actually fails if I set the breakpoint after k is defined. So that part of my original post should be ignored. When I tried a small test case before, I had not used the same flags as caused failure. I just tried such a case, and it worked, so no luck in generating a small test case.
[Bug c++/56607] [4.8/4.9 regression] GCC fails to warn on division by zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56607 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-16 19:35:48 UTC --- Author: jakub Date: Sat Mar 16 19:35:41 2013 New Revision: 196704 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196704 Log: PR c++/56607 * typeck.c (cp_build_binary_op): When calling warn_for_div_by_zero, pass op1 through maybe_constant_value first. * g++.dg/warn/Wdiv-by-zero-2.C: New test. * c-c++-common/pr56607.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr56607.c trunk/gcc/testsuite/g++.dg/warn/Wdiv-by-zero-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638 Bug #: 56638 Summary: Linker uses a lot of memory in Fortran 77 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncc1701...@gmail.com Hi. I hope this is not a repeated bug. I haven't found a similar bug. I'm using gfortran 4.6.3 in a Raspberry Pi (ARM architecture). When compiling a Fortran 77 file, I've noticed that in the linking process, it uses as much RAM as declared in all the variables. The executable generated is small and the execution doesn't uses so much RAM if the full array is not addressed. I have a software that reserves a lot of RAM (because Fortran 77 doesn't support dynamically assigned memory) but it won't address the entire range. I cannot compile it in the Raspberry Pi, but it compiles fine in a x86 linux and in Cygwin. Example program: PROGRAM BUG IMPLICIT NONE INTEGER LARGE(1) LARGE(1)=1 END Compile the object, this works fine: gfortran -c program.f Generate the executable. This uses over 400 MB of RAM (100.000.000 elements of 4 bytes): gfortran -o program program.f If you increase the length of the array LARGE in the code, it will use more and more RAM. Full output of the compiler version: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) Is this considered a bug? Thanks! Best regards.
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 19:46:07 UTC --- Author: redi Date: Sat Mar 16 19:45:53 2013 New Revision: 196706 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196706 Log: PR libstdc++/56002 * include/std/mutex (lock_guard, unique_lock, lock): Define without depending on _GLIBCXX_HAS_GTHREADS. * testsuite/30_threads/lock_guard/cons/1.cc: Run on all targets. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/mutex trunk/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.3 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 19:52:42 UTC --- Fixed on trunk so far, the fix will also be done for 4.7.3 and 4.8.1
[Bug libstdc++/56468] Clang exposes bug with unexpected forward-declaration of type_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 20:01:27 UTC --- Author: redi Date: Sat Mar 16 20:01:16 2013 New Revision: 196709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196709 Log: PR libstdc++/56468 * libsupc++/exception_ptr.h (type_info): Declare. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/exception_ptr.h
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 20:22:40 UTC --- Author: redi Date: Sat Mar 16 20:22:30 2013 New Revision: 196710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196710 Log: PR libstdc++/56002 * include/std/mutex (lock_guard, unique_lock, lock): Define without depending on _GLIBCXX_HAS_GTHREADS. * testsuite/30_threads/lock_guard/cons/1.cc: Run on all targets. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/std/mutex branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
[Bug libstdc++/56468] Clang exposes bug with unexpected forward-declaration of type_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 20:22:57 UTC --- Author: redi Date: Sat Mar 16 20:22:40 2013 New Revision: 196711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196711 Log: PR libstdc++/56468 * libsupc++/exception_ptr.h (type_info): Declare. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/exception_ptr.h
[Bug libstdc++/56468] Clang exposes bug with unexpected forward-declaration of type_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.3 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-16 20:23:58 UTC --- Fixed on trunk and 4.7 branch so far, the fix will also be done for 4.8.1
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-16 21:22:43 UTC --- The symptoms you describe could indicate a classic error like an index out of bounds error, an argument mismatch or a variable which has not been set. You could run your program under valgrind, and see if you find anything. You could also look the output from -fdump-tree-original to see if anything looks wrong.
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #5 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 21:25:46 UTC --- I don't mean to be argumentative, but I would like to ask: Would an index out of bounds explain why single stepping over the statement make it work, and would it explain that a higher level of optimization works?
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-16 21:36:54 UTC --- I don't mean to be argumentative, but I would like to ask: Would an index out of bounds explain why single stepping over the statement make it work, and would it explain that a higher level of optimization works? Absolutely: all the errors mentioned by Thomas give behaviors sensitive to the memory layout! However if you compile with -fcheck=bounds, out of bounds error(s) should be detected. Did you check that you pass the right arguments (position, type, kind, ...) to the procedures in the libraries you are using?
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #7 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 21:44:46 UTC --- As mentioned in my first post, I am compiling with -fcheck-bounds. The errors are occurring in a subroutine inside what at the moment is a main program. That subroutine has no arguments. As this is code in the process of being developed, I have had run time errors for indexes being out of bounds. It turns out as a result of thinking more about the problems I'm dealing with (algorithmic issues) this part of the code is likely to disappear. I do appreciate others trying to find my problem, that is very nice. I was posting in the hope that I might help someone in finding a compiler bug.
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-16 23:03:06 UTC --- I was posting in the hope that I might help someone in finding a compiler bug. And we do appreciate that very much. The problem is that without a self-contained example (i.e. one which compiles and shows the erroneous behavior) we cannot do much. If you can upload something which reproduces the problem, even if it is large, we could then try to find the issue. Would that be possible for you?
[Bug libstdc++/56468] Clang exposes bug with unexpected forward-declaration of type_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2013-03-16 23:46:08 UTC --- (In reply to comment #7) Fixed on trunk and 4.7 branch so far, the fix will also be done for 4.8.1 It's unusual for a bug to be fixed for a previous release and for trunk, but not on the latest release. Isn't this worth applying to GCC 4.8.0 also? The patch looks safe and simple enough...
[Bug fortran/56638] Linker uses a lot of memory in Fortran 77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||INVALID --- Comment #1 from kargl at gcc dot gnu.org 2013-03-17 01:24:10 UTC --- (In reply to comment #0) I have a software that reserves a lot of RAM (because Fortran 77 doesn't support dynamically assigned memory) but it won't address the entire range. gfortran is a Fortran 95 compiler. Learn to use dynamic memory allocation or lower expectations with regards to declaring arrays that consume a large amount of memory.
[Bug c/56635] [4.8 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635 --- Comment #2 from Orion Poplawski orion at cora dot nwra.com 2013-03-17 01:44:29 UTC --- Created attachment 29682 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29682 Preprocessed source Sorry, looks like it was too big. Here it is compressed.
[Bug c++/56095] [4.6/4.7 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:33:46 UTC --- Author: jason Date: Sun Mar 17 02:33:38 2013 New Revision: 196722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196722 Log: PR c++/56095 * class.c (resolve_address_of_overloaded_function): Accept a reference to function for target_type. (instantiate_type): Likewise. * pt.c (convert_nontype_argument): Pass it to convert_nontype_argument_function. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/pt.c
[Bug debug/49090] provide a way to recognize defaulted template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:33:59 UTC --- Author: jason Date: Sun Mar 17 02:33:50 2013 New Revision: 196723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196723 Log: PR debug/49090 * dwarf2out.c (gen_generic_params_dies): Indicate default arguments with DW_AT_default_value. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/langhooks.h
[Bug c++/56238] [4.7 regression] ICE in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2515
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56238 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:34:17 UTC --- Author: jason Date: Sun Mar 17 02:34:03 2013 New Revision: 196724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196724 Log: PR c++/56238 * pt.c (fold_non_dependent_expr_sfinae): Check instantiation_dependent_expression_p. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/55241] [C++11] diagnostics show sizeof...(T) as sizeof(T...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55241 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:34:45 UTC --- Author: jason Date: Sun Mar 17 02:34:31 2013 New Revision: 196726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196726 Log: PR c++/55241 * error.c (dump_expr) [SIZEOF_EXPR]: Print sizeof... properly. Added: trunk/gcc/testsuite/g++.dg/diagnostic/variadic1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug c++/55240] [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55240 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:35:01 UTC --- Author: jason Date: Sun Mar 17 02:34:45 2013 New Revision: 196727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196727 Log: PR c++/55240 * parser.c (parsing_nsdmi): New. * semantics.c (outer_automatic_var_p): Check it. (finish_id_expression): Likewise. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-local.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c
[Bug c++/55017] [DR 1051] [C++11] Rvalue-reference member should cause copy constructor to be deleted, but still declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55017 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:35:18 UTC --- Author: jason Date: Sun Mar 17 02:35:01 2013 New Revision: 196728 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196728 Log: PR c++/55017 * method.c (walk_field_subobs): Disallow copy of rvalue ref. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-copy1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/pair/piecewise2.cc
[Bug c++/56447] [C++11] Lambda in template has conversion op it shouldn't have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56447 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:35:34 UTC --- Author: jason Date: Sun Mar 17 02:35:18 2013 New Revision: 196729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196729 Log: PR c++/56447 PR c++/55532 * pt.c (instantiate_class_template_1): Instantiate lambda capture list here. (tsubst_copy_and_build): Not here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv8.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mutable2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/55532] Runtime segfault calling mutable lambda wrapped in a non-mutable lambda within a template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55532 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:35:35 UTC --- Author: jason Date: Sun Mar 17 02:35:18 2013 New Revision: 196729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196729 Log: PR c++/56447 PR c++/55532 * pt.c (instantiate_class_template_1): Instantiate lambda capture list here. (tsubst_copy_and_build): Not here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv8.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mutable2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/54946] ICE on template parameter from cast char-pointer in C++11 constexpr struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54946 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:36:09 UTC --- Author: jason Date: Sun Mar 17 02:35:50 2013 New Revision: 196731 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196731 Log: PR c++/54946 * pt.c (convert_nontype_argument): Handle invalid pointer. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:36:25 UTC --- Author: jason Date: Sun Mar 17 02:36:08 2013 New Revision: 196732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196732 Log: DR 1518 PR c++/54835 * call.c (convert_like_real): Check for explicit constructors even for value-initialization. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C
[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232 --- Comment #18 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:36:54 UTC --- Author: jason Date: Sun Mar 17 02:36:40 2013 New Revision: 196734 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196734 Log: DR 337 PR c++/17232 * pt.c (tsubst) [ARRAY_TYPE]: Use abstract_virtuals_error_sfinae. * typeck2.c (abstract_virtuals_error_sfinae): Call complete_type. Added: trunk/gcc/testsuite/g++.dg/template/abstract-dr337.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:37:21 UTC --- Author: jason Date: Sun Mar 17 02:37:09 2013 New Revision: 196736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196736 Log: N3276 PR c++/52748 * cp-tree.h (tsubst_flags): Add tf_decltype. * call.c (build_cxx_call): Don't build a temporary if it's set. (build_over_call): Make sure it's only passed to build_cxx_call. * parser.c (cp_parser_primary_expression): Add decltype_p parm. (cp_parser_unary_expression): Likewise. (cp_parser_cast_expression): Likewise. (cp_parser_binary_expression): Likewise. (cp_parser_assignment_expression): Likewise. (cp_parser_postfix_expression): Likewise. Pass tf_decltype. (cp_parser_explicit_instantiation): Add decltype_p. Force a temporary for a call on the LHS of a comma. (cp_parser_decltype): Pass true to decltype_p parms. * pt.c (tsubst) [DECLTYPE_TYPE]: Pass tf_decltype. (tsubst_copy_and_build): Pass tf_decltype down only for CALL_EXPR and the RHS of COMPOUND_EXPR. * tree.c (build_cplus_new): Call complete_type_or_maybe_complain. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype-call1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c
[Bug c++/56481] [4.8 Regression] endless loop compiling a C++ file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56481 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:37:34 UTC --- Author: jason Date: Sun Mar 17 02:37:21 2013 New Revision: 196737 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196737 Log: PR c++/56481 * semantics.c (potential_constant_expression_1): Use of 'this' in a non-constexpr function makes the expression not potentially constant. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/55357] -Wshadow warns about lambda function parameters matching variables in outer scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55357 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:38:16 UTC --- Author: jason Date: Sun Mar 17 02:38:01 2013 New Revision: 196739 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196739 Log: PR c++/55357 * semantics.c (maybe_add_lambda_conv_op): Clear DECL_NAME of copied parms to avoid duplicate -Wshadow warnings. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/54359] [C++0x] decltype in member function's trailing return type when defined outside of class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54359 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:38:34 UTC --- Author: jason Date: Sun Mar 17 02:38:21 2013 New Revision: 196740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196740 Log: PR c++/54359 * parser.c (cp_parser_direct_declarator): Fix late return for out-of-class defn of member function. Added: trunk/gcc/testsuite/g++.dg/cpp0x/trailing8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:38:49 UTC --- Author: jason Date: Sun Mar 17 02:38:35 2013 New Revision: 196741 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196741 Log: PR c++/56039 * tree.c (strip_typedefs_expr): Complain about lambda, don't abort. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-sfinae1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/54764] In class initialization of non-static lambda member can't be used in class with default template paramer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54764 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:39:05 UTC --- Author: jason Date: Sun Mar 17 02:38:50 2013 New Revision: 196742 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196742 Log: PR c++/54764 PR c++/55972 * name-lookup.h (tag_scope): Add ts_lambda. * semantics.c (begin_lambda_type): Use it. * decl.c (xref_tag_1): Set CLASSTYPE_LAMBDA_EXPR. * pt.c (check_default_tmpl_args): Ignore lambdas. (push_template_decl_real): Handle lambdas. * tree.c (no_linkage_check): Adjust lambda check. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg4.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug c++/55972] cannot access private member from lambda used in NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:39:03 UTC --- Author: jason Date: Sun Mar 17 02:38:50 2013 New Revision: 196742 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196742 Log: PR c++/54764 PR c++/55972 * name-lookup.h (tag_scope): Add ts_lambda. * semantics.c (begin_lambda_type): Use it. * decl.c (xref_tag_1): Set CLASSTYPE_LAMBDA_EXPR. * pt.c (check_default_tmpl_args): Ignore lambdas. (push_template_decl_real): Handle lambdas. * tree.c (no_linkage_check): Adjust lambda check. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg4.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug c++/52374] [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:39:18 UTC --- Author: jason Date: Sun Mar 17 02:39:04 2013 New Revision: 196743 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196743 Log: PR c++/52374 * pt.c (tsubst_qualified_id): Use current_nonlambda_class_type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/45917] inaccessible types allowed as template argument in nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45917 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:39:39 UTC --- Author: jason Date: Sun Mar 17 02:39:22 2013 New Revision: 196744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196744 Log: PR c++/45917 * parser.c (cp_parser_template_id): Don't forget access checks. Added: trunk/gcc/testsuite/g++.dg/template/access26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/55931] [C++11] Constexpr member function inside a static member is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:40:06 UTC --- Author: jason Date: Sun Mar 17 02:39:51 2013 New Revision: 196746 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196746 Log: PR c++/55931 * parser.c (cp_parser_template_argument): Don't fold_non_dependent_expr. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/54277] Template class member referred to with implicit this inside lambda is incorrectly const-qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-17 02:41:35 UTC --- Author: jason Date: Sun Mar 17 02:41:22 2013 New Revision: 196747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196747 Log: PR c++/54277 * cp-tree.h (WILDCARD_TYPE_P): Split out from... (MAYBE_CLASS_TYPE_P): ...here. * semantics.c (lambda_capture_field_type): Only build a magic decltype for wildcard types. (lambda_proxy_type): Likewise. (finish_non_static_data_member): Get the quals from the object. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #9 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-17 04:42:39 UTC --- I have tried, but the small examples I've tried all work. And the code uses a library that I am not free to pass on. Probably you just have to call this unconfirmed and forget it. Sorry.
[Bug c/56635] [4.8 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2013-03-17 04:44:38 UTC ---
markus@x4 tmp % cat test.ii
templatetypenamestruct A;
templatetypename _TpA_Tpoperator/(A_Tp, A_Tp p2)
{
A_Tp a;
a /= p2;
return a;
}
templatetypename _Tpbool operator!=(A_Tp p1, A_Tp)
{
return p1.real();
}
templatestruct Adouble
{
double real()
{
return __real__ _M_value;
}
templatetypename _Tpvoid operator/=(A_Tp)
{
_M_value /= 10;
}
_Complex double _M_value;
};
templateclass Tclass B {
T *buf;
public:
B(int, bool);
T operator[](int)
{
return buf[0];
}
};
struct C
{
C(const int);
typedef AdoubleTy;
typedef BTyDataT;
Adoublezero;
enum InitType
{ NOZERO };
virtual C* DivInv(C *);
};
templateclass Spclass D : Sp {
typedef typename Sp::TyTy;
typedef typename Sp::DataT DataT;
DataT dd;
public:
D(const int, C::InitType);
Ty operator[](int)
{
return dd[0];
}
D* DivInv(C *);
};
templateclass SpDSp *DSp::DivInv(C *)
{
if ((*this)[0] != this-zero) (*this)[0] = (*static_castD *(0))[0] /
(*this)[0];
else (*this)[0] = (*static_castD *(0))[0];
return 0;
}
DC *b = new DC(0, C::NOZERO);
templateclass SpDSp::D(const int, C::InitType) : Sp(0), dd(0, 0)
{}
markus@x4 tmp % c++ -Wextra -Wall -c -O3 test.ii
test.ii: In member function ‘DSp* DSp::DivInv(C*) [with Sp = C]’:
test.ii:67:26: internal compiler error: in find_lattice_value, at
tree-complex.c:151
templateclass SpDSp *DSp::DivInv(C *)
^
[Bug tree-optimization/56635] [4.8 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |4.8.0
