[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #14 from philip.copeland at oracle dot com 2013-01-09 08:27:19 UTC --- Smallest test case program #include iostream int main() { std::cerr we are able to write to stderr\n; } bash-4.2# g++ test.c bash-4.2# ./a.out we are able to write to stderr Segmentation fault (core dumped) #0 0xf8010030a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6 #1 0xf80100180988 in __cxxabiv1::__cxa_get_globals () at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 #2 0xf801001807cc in std::uncaught_exception () at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136 #3 0xf801001bcbe4 in ~sentry (this=0x7fef0b0, __in_chrg=optimized out) at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429 #4 std::__ostream_insertchar, std::char_traitschar (__out=..., __s=__s@entry=0x100a00 we are able to write to stderr\n, __n=optimized out) at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112 #5 0xf801001bcfc4 in std::operator std::char_traitschar ( __out=..., __s=0x100a00 we are able to write to stderr\n) at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:533 #6 0x0010087c in main ()
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #49 from richard.guenther at gmail dot com richard.guenther at gmail dot com 2013-01-09 08:52:21 UTC --- On Tue, Jan 8, 2013 at 8:52 PM, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-08 19:52:39 UTC --- From comment #40: with -ffast-math, so for example if (x != 0) tem = y / x; else tem = 0.; ... do sth with tem ... will execute y / x unconditionally based on the fact that it cannot trap. This optimization generates an exception trapped when using -ffpe-trap=invalid along with -ffast-math. This unfortunately prevents any debugging based -ffpe-trap=invalid for miscompilations occurring with -ffast-math. Well - that's maybe unfortunate but expected. You can't have both ;) One thing I hope, though I am not sure about it, is that the above block is still compiled as tem=y/x if (x==0) tem=0. Yes, it's basically turned into an unconditional divide plus a conditional move based on the fact that we cannot vectorize non-straight-line-code (so it's really only a vectorization enabler). My original report was for '-O3 -funsafe-math-optimizations -ffinite-math-only' without -ffpe-trap=invalid. The segmentation fault resulted from the fact that some variables were used to access a table and were out of bound when the miscompilation generated some NAN (see comment #13). Yes, that's another common issue - with FP indexing even slight rounding differences can cause bogus accesses (consider producing a[0.99] instead of a[1.0]). That mostly happens with FP loop induction variables that are also used for indexing (a really bad practice the frontend should warn about - at least when -funsafe-math-optimizations is in effect). Richard. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug tree-optimization/55912] missing optimization of x/x and x/std::abs(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55912 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2013-01-09 08:59:26 UTC --- Thanks. Hmm, what I was suggesting in the other bug (trivial code in fold-const.c) would probably only help for sign2, and only if you use fabsf instead of std::abs :-(
[Bug tree-optimization/48189] [4.6/4.7/4.8 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 09:00:32 UTC --- Author: jakub Date: Wed Jan 9 09:00:22 2013 New Revision: 195046 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195046 Log: PR tree-optimization/48189 * predict.c (predict_loops): If max is 0, don't call compare_tree_int. If nitercst is 0, don't predict the exit edge. * gcc.dg/pr48189.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48189.c Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48189] [4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE: |ICE: SIGFPE (division by|SIGFPE (division by zero) |zero) in in predict_loops |in in predict_loops () at |() at predict.c:991 with|predict.c:991 with --param |--param |max-predicted-iterations=0 |max-predicted-iterations=0 | --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 09:03:38 UTC --- Fixed on the trunk so far.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #15 from philip.copeland at oracle dot com 2013-01-09 09:06:38 UTC --- I've a fc17 x86_64 box in the backroom here that I'm going to generate a comparison trace with [root@ZenV tmp]# gdb a.out (gdb) break ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 No symbol table is loaded. Use the file command. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (../../../../libstdc++-v3/libsupc++/eh_globals.cc:63) pending. (gdb) run Starting program: /tmp/a.out we are able to write to stderr Breakpoint 1, __cxxabiv1::__cxa_get_globals () at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 63 { return get_global(); } (gdb) where #0 __cxxabiv1::__cxa_get_globals () at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 #1 0x00354f25e0d9 in std::uncaught_exception () at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136 #2 0x00354f295a12 in ~sentry (this=0x7fffe360, __in_chrg=optimized out) at /usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:429 #3 std::__ostream_insertchar, std::char_traitschar (__out=..., __s=__s@entry=0x400870 we are able to write to stderr\n, __n=31) at /usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112 #4 0x00354f295d8f in std::operator std::char_traitschar ( __out=..., __s=0x400870 we are able to write to stderr\n) at /usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:533 #5 0x0040075f in main () (gdb) step std::uncaught_exception () at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:137 137 return globals-uncaughtExceptions != 0; (gdb) list 132 133 bool 134 std::uncaught_exception() throw() 135 { 136 __cxa_eh_globals *globals = __cxa_get_globals (); 137 return globals-uncaughtExceptions != 0; 138 }
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 09:07:24 UTC --- We no longer ICE in the testcase. We still regress by missing devirtualization in new ipa-cp implementation and I would like Martin to double check that the right thing happens when combining the ancestor jump function. No ICE, no wrong code, so no longer P1 I guess.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 09:22:21 UTC --- (In reply to comment #11) All that to avoid one #include output.h in one file? Is that one little thing really the only change you see? I see a different picture. The change is a major step in the direction of making a clear cut between the middle/back end and the front ends. A front end should not output assembly, period, if we want the front ends to become separate libraries, in the long run, that can be used by external tools (static checkers, IDEs, etc.) like clang. For the long term, this is IMHO the only viable solution for keeping the GCC front ends relevant. The change also allows the compiler to open the assembler file in write-only mode and to open it only after the front end is done. My plan is to postponed it even further: for GCC 4.9 I'd like to work on streaming slim LTO objects directly to a .o file, without going through an assembler file at all (this is relatively simple for ELF targets). Finally, the change also simplifies the PCH mechanism further. If we're ever going to replace PCH-as-a-memory-dump with something streamed, we'll have to make an effort at only streaming IR objects, not assembler output. Had I known this change would break stabs like this, I'd obviously have tried to solve that problem first. But to back out the change now would be a mistake. Nobody is going to fix those *out.c back ends, as you very well know. That's exactly my thinking of the whole picture. Timing seems to be bad now - so as compromise I'd accept reverting the patch for 4.8 and immediately re-installing it when stage1 for 4.9 re-opens. If dwarf2out.c is really set up nicely enough (just dump its internal dwarf tree to asm_out_file at some point) then doing dwarf - Y translation at that point should be possible. Of course I don't see anybody doing that either - nobody is really interested in debug formats besides dwarf apart from keeping the legacy going. IMHO we can direct them to use oder versions of GCC. Thus, let's deprecate anything but dwarf in 4.8 ;)
[Bug tree-optimization/55912] missing optimization of x/x and x/std::abs(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55912 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-09 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 09:26:58 UTC --- Most of the math builtin folding needs to be re-done at GIMPLE level based on SSA form. Convenient places are either tree-ssa-forwprop.c or tree-ssa-math-opts.c (sincos pass which also does power series expansion now).
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 09:31:45 UTC --- (In reply to comment #17) gimple_location is duplicated by: #1 0x00751f32 in gimple_copy (stmt=0x7fffe8d75a00) at /export/gnu/import/git/gcc/gcc/gimple.c:2205 #2 0x009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0) at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397 #3 0x005b27a5 in duplicate_block (bb=0x7fffe8d768f0, e=0x7fffe8d793f0, after=0x7fffe8d76888) at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012 #4 0x0099c511 in tail_duplicate () at /export/gnu/import/git/gcc/gcc/tracer.c:323 #5 0x0099c765 in tracer () at /export/gnu/import/git/gcc/gcc/tracer.c:380 #6 0x008ae0e6 in execute_one_pass (pass=0x16d18a0 pass_tracer) at /export/gnu/import/git/gcc/gcc/passes.c:2335 #7 0x008ae2da in execute_pass_list (pass=0x16d18a0 pass_tracer) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #8 0x008ae30b in execute_pass_list ( pass=0x16d07e0 pass_all_optimizations) at /export/gnu/import/git/gcc/gcc/passes.c:2384 #9 0x005da366 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #10 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 (gdb) p copy $176 = (gimple) 0x7fffe8e0a320 (gdb) The BLOCK of the location is kept live by being referenced by the stmt copy (what kind is the stmt? the only stmt not well handled seems to be CLOBBERs) Later, the original location is removed: #0 remove_unused_locals () at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:793 #1 0x008ad5cb in execute_function_todo (data=0x8800) at /export/gnu/import/git/gcc/gcc/passes.c:1952 #2 0x008ac965 in do_per_function ( callback=0x8ad4ae execute_function_todo(void*), data=0x8800) at /export/gnu/import/git/gcc/gcc/passes.c:1703 #3 0x008ad765 in execute_todo (flags=34816) at /export/gnu/import/git/gcc/gcc/passes.c:2001 #4 0x008ae175 in execute_one_pass ( pass=0x16d3220 pass_cleanup_cfg_post_optimizing) at /export/gnu/import/git/gcc/gcc/passes.c:2349 #5 0x008ae2da in execute_pass_list ( pass=0x16d3220 pass_cleanup_cfg_post_optimizing) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #6 0x005da366 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #7 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 and freed. You probably mean BLOCK - it should be still live as referenced from the stmt, or cleaned from the stmt if it was a debug stmt. Then we copy the freed gimple_location: #0 expand_gimple_stmt_1 (stmt=0x7fffe8e0a320) at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2202 #1 0x005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320) at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305 #2 0x005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888, disable_tail_calls=false) at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084 #3 0x005af426 in gimple_expand_cfg () at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603 #4 0x008ae0e6 in execute_one_pass (pass=0x16ce300 pass_expand) at /export/gnu/import/git/gcc/gcc/passes.c:2335 #5 0x008ae2da in execute_pass_list (pass=0x16ce300 pass_expand) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #6 0x005da366 in expand_function (node=0x717536f0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #7 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 #8 0x005db2ab in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043 #9 0x0053c60a in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390 #10 0x00999401 in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:545
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 09:32:21 UTC --- Fixed instead. Missed devirt is something completely different.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #3 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 09:44:07 UTC --- Please find below my interpretation of the validity or not of the testcase for this PR. The following test is probably invalid, but not rejected by recent trunk versions: type :: t procedure(a), pointer, nopass :: p end type type(t) :: x procedure(iabs), pointer :: pp x%p = a ! ok [A] I believe that this is invalid because the interfaces do not match procedure(iabs), pointer = integer pointer procedure (integer formal) It strikes me as being a moot point as to whetehr or not the processor is required to report it though, on the gorunds that anything goes with pointers! That said, the interface check is easy to implement. x%p = a(1) ! invalid, but not rejected by 4.8 [B] This is valid: procedure(iabs), pointer = pointer to integer procedure(iabs) It has the pleasing property of providing the correct result for print *, x%p(-99) .eq. iabs(-99) pp = a(2) ! ok [B] applies - it also gives the correct result. pp = a ! invalid, but not rejected by 4.8 [A] applies - invalid. contains function a (c) result (b) integer, intent(in) :: c procedure(iabs), pointer :: b b = iabs end function end Interestingly, both invalid lines run and provide results that are consistent with INT (loc (iabs)) :-) Paul
[Bug tree-optimization/55913] New: ipa-cp should consider also constants implied by the context it is clonning for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55913 Bug #: 55913 Summary: ipa-cp should consider also constants implied by the context it is clonning for Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org In the following testcase (devirt10-C) ipa-cp should devirtualize both calls class wxPaintEvent { }; struct wxDCBase { wxDCBase (); virtual int GetLayoutDirection() const{} virtual void SetLayoutDirection(int){} }; struct wxWindowDC : public wxDCBase {}; struct wxBufferedDC : public wxDCBase { void Init(wxDCBase*dc) { InitCommon(dc); } void InitCommon(wxDCBase*dc) { if (dc) SetLayoutDirection(dc-GetLayoutDirection()); } }; struct wxBufferedPaintDC : public wxBufferedDC { wxBufferedPaintDC() { Init(m_paintdc); } wxWindowDC m_paintdc; }; void OnPaint(wxPaintEvent event) { wxBufferedPaintDC dc; } On all calls both THIS and DC binfos are known. There is no need to create clone for THIS binfo known and DC unknown as it is done presently.
[Bug c++/55910] One of instances generated for a method with -O3 uses incorrect parameter cleanup size with 'ret'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55910 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-09 09:55:35 UTC --- IMHO, I've localized the issue clearly enough. The code that generates instances for methods may sometimes consider some of those instances as having no parameters in method instance itself and as having some nonzero size of parameters (namely 0x38) in caller that re-adjusts stack after method instance has cleared the parameters. If those numbers would be taken from single variable that kind of bug would be impossible. So please examine the code and see where do you get total parameter size for 'ret' instruction from and where do you get total parameter size for stack re-adjustment from. And then please try to realize why those locations could possibly have different numbers in them. When -O2 is enabled, there are dozens of different passes massaging the initial code and trying to optimize it. It is essentially impossible to predict how they interact with each other given the complexity explosion, that's why being able to replay the compilation is required. The rules are clear: if you want the GCC team to look at your problem, you must provide a reproducer. Otherwise this PR will be closed as WONTFIX.
[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55911 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-09 CC||fdumont at gcc dot gnu.org, ||frs.dumont at gmail dot com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:08:19 UTC --- I can reproduce this. Francois can you have a look ASAP? Thanks in advance.
[Bug c++/55914] New: [C++11] Pack expansion for class member expression fails in lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914 Bug #: 55914 Summary: [C++11] Pack expansion for class member expression fails in lambda expressions Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com The following code, compiled with -Wall -std=c++11 -pedantic is rejected by gcc 4.7.2 and gcc 4.8.0 20130106 (experimental): //- struct S { int foo(){ return 0; } }; templateclass... Args void evaluate(Args...){} template class... Args void bar(Args... args) { evaluate(args.foo()...); // OK auto lmb = [=](){ evaluate(args.foo()...); }; // Error lmb(); } int main() { S s{}; bar(s); } //- 11|error: parameter packs not expanded with '...':| 11|note: 'args'| In instantiation of 'void bar(Args ...) [with Args = {S}]':| 17|required from here| 11|error: using invalid field 'bar(Args ...)::__lambda0::__args'| The problem also occurs for class member expressions of the form E1-E2 instead of E1.E2.
[Bug c/55915] New: fails to build lto-compress.c, zlib.h not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55915 Bug #: 55915 Summary: fails to build lto-compress.c, zlib.h not found Classification: Unclassified Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: alex...@gmail.com I have trouble with building GCC from trunk with system zlib. My configure line is: configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/temp/x64-trunk-snapshot-posix-seh-rev3/prefix --with-sysroot=/temp/x64-trunk-snapshot-posix-seh-rev3/prefix --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-cloog-backend=isl --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-ppl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-host-libstdcxx=-static -lstdc++ --with-libiconv --with-system-zlib --with-gmp=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-mpfr=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-mpc=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-ppl=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-cloog=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-pkgversion=Built by MinGW-builds project --with-bugurl=http://sourceforge.net/projects/mingwbuilds/ CFLAGS=-O2 -pipe -fomit-frame-pointer -I/temp/x64-trunk-snapshot-posix-seh-rev3/libs/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include -I/temp/mingw-prereq/x64-zlib/include CXXFLAGS=-O2 -pipe -fomit-frame-pointer CPPFLAGS= LDFLAGS=-pipe -L/temp/x64-trunk-snapshot-posix-seh-rev3/libs/lib -L/temp/mingw-prereq/x86_64-w64-mingw32-static/lib -L/temp/x64-trunk-snapshot-posix-seh-rev3/prefix/opt/lib -L/temp/mingw-prereq/x64-zlib/lib I have prebuilded zlib in /temp/mingw-prereq/x64-zlib. During build I nave error: x86_64-w64-mingw32-g++ -c -O2 -pipe -fomit-frame-pointer -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../../../mingw-sources/gcc-trunk/gcc -I../../../../mingw-sources/gcc-trunk/gcc/. -I../../../../mingw-sources/gcc-trunk/gcc/../include -I../../../../mingw-sources/gcc-trunk/gcc/../libcpp/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include -I../../../../mingw-sources/gcc-trunk/gcc/../libdecnumber -I../../../../mingw-sources/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../../../mingw-sources/gcc-trunk/gcc/../libbacktrace ../../../../mingw-sources/gcc-trunk/gcc/lto-compress.c -o lto-compress.o ../../../../mingw-sources/gcc-trunk/gcc/lto-compress.c:28:18: fatal error: zlib.h: No such file or directory compilation terminated. make[2]: *** [lto-compress.o] Error 1 make[2]: Leaving directory `/temp/x64-trunk-snapshot-posix-seh-rev3/build/gcc-trunk/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/temp/x64-trunk-snapshot-posix-seh-rev3/build/gcc-trunk' make: *** [all] Error 2
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #16 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 10:13:02 UTC --- Something is seriously broken in Philip's environment or his gcc-4.7 build. I get fairly clean g++/libstdc++ test suite results with vanilla 4.7 on Fedora 15/sparc64 + kernel 3.8-rc2, see e.g. http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html. One thing that differs is that my gcc is configured for 32-bit code by default with the ability to generate 64-bit code when requested (--target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all), whereas I assume that Philip's sparc64 rpms are 64-bit binaries generating 64-bit code by default. I could do a pure 64-bit bootstrap + regtest in a day or two, just to check.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:18:34 UTC --- Thanks Mikael. Thus I suppose the minimized snippet in Comment #14 also runs fine for you? Indeed, it would be nice if you could try to reproduce the exact problem Philip is seeing in a pure 64-bit setup.
[Bug c++/55914] [C++11] Pack expansion for class member expression fails in lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Blocks||54367 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:23:56 UTC --- I suspect this is just a different manifestation of PR41933.
[Bug c++/55900] [C++11]internal compiler error with initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55900 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:28:52 UTC --- The 2nd testcase in PR55753 is now also fixed.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #18 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 10:32:35 UTC --- Yes, the snippet in Comment #14 works fine for me, with both -m32 and -m64.
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-09 10:36:02 UTC --- Unfortunately, that causes the following failures: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o-cp_lto_20081217-2_0.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o-cp_lto_20081217-2_0.o link, -O2 -flto -fuse-linker-plugin (internal compiler error) g++.dg/torture/pr34099.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) g++.dg/torture/pr45934.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) g++.dg/torture/pr45934.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) g++.dg/torture/pr47382.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) g++.dg/torture/pr47382.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) Let me look into those...
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #19 from philip.copeland at oracle dot com 2013-01-09 10:37:38 UTC --- Mikael, could you compare against the versions of packages that I'm using? gcc requires the following according to fedora) cloog-ppl-0.15.11-4.fc18.1.sparc64 cpp-4.7.2-8.fc18.sparc64 libmpc-0.9-3.fc18.2.sparc64 mpfr-3.0.0-4.fc18.sparc64 gmp-5.0.5-3.fc18.sparc64 binutils-2.23.51.0.1-3.fc18.sparc64 gcc-4.7.2-8.fc18.sparc64 glibc-2.16-28.fc18.sparc64 elfutils-0.155-2.fc18.sparc64 * modified as per https://bugzilla.redhat.com/attachment.cgi?id=672431action=diff * Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT patches that the fc* packages normally gets added, applied? Thanks
[Bug c++/55914] [C++11] Pack expansion for class member expression fails in lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-09 10:39:29 UTC --- (In reply to comment #1) I suspect this is just a different manifestation of PR41933. Thanks Paolo, I partially agree. Indeed the problem is not depending on class member expressions (so the issue title should be fixed), a simplified example can be written as: // struct S {}; templateclass... Args void evaluate(Args...){} template class... Args void bar(Args... args) { evaluate(args...); // OK auto lmb = [=](){ evaluate(args...); }; // Error lmb(); } int main() { S s{}; bar(s); } // with the error: 9|error: parameter packs not expanded with '...':| 9|note: 'args'| 9|error: expansion pattern 'args' contains no argument packs| |In instantiation of 'void bar(Args ...) [with Args = {S}]':| 15|required from here| 9|error: using invalid field 'bar(Args ...)::__lambda0::__args'| The reason why I hesitate to agree with that being a dup of bug 41933 is due to the fact that the corresponding example there depends on a language extension described in http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#904 that is not part of C++11. I do think though, that my revised example above is indeed conforming C++11 because it does not depend on that grammar extension. Please keep that in mind when considering the category change to DUP, because that would have impact on which versions of gcc to patch. For example, I assume that any CWG defect 904 association would presumably not be applied to gcc 4.7.2.
[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|WAITING |NEW CC||ebotcazou at gcc dot ||gnu.org, rguenth at gcc dot ||gnu.org Component|c |middle-end Target Milestone|--- |4.7.3 Summary|unaligned load/store : |[4.7/4.8 Regression] |incorrect struct offset |unaligned load/store : ||incorrect struct offset --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 10:41:28 UTC --- Eric, I am double-checking my patch and I believe all this 'bitpos' handling in set_mem_attributes_minus_bitpos (and/or MEM_OFFSET in general) looks suspicious. /* For a MEM rtx, the offset from the start of MEM_EXPR. */ #define MEM_OFFSET(RTX) (get_mem_attrs (RTX)-offset) I read from this that the XEXP (RTX, 0) points to MEM_EXPR + MEM_OFFSET (if MEM_OFFSET_KNOWN_P, and if !MEM_OFFSET_KNOWN_P we don't know how XEXP (RTX, 0) and MEM_EXPR relate). Now, in expand_assignment we do tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset); ... to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE); ... offset it with variable parts from 'offset' ... set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos); but bitpos here is _not_ ontop of 'to' but extracted from 'to' (and eventually modified by get_bit_range which may shift things to 'offset'). The only 'bitpos' that should be passed to set_mem_attributes_minus_bitpos is one that reflects - in the bitfield access case - that we actually access things at a different position. But at this point we don't know what optimize_bitfield_assignment_op or store_field will eventually do. Also MEM_OFFSET is in bytes while I believe 'bitpos' can end up as an actual bit position, so /* If we modified OFFSET based on T, then subtract the outstanding bit position offset. Similarly, increase the size of the accessed object to contain the negative offset. */ if (apply_bitpos) { gcc_assert (attrs.offset_known_p); attrs.offset -= apply_bitpos / BITS_PER_UNIT; if (attrs.size_known_p) attrs.size += apply_bitpos / BITS_PER_UNIT; } (whatever this comment means). I believe my fix is correct following the MEM_OFFSET description and guessing at what the argument to set_mem_attributes_minus_bitpos means by looking at its use. But I believe that expand_assignment should pass zero as bitpos to set_mem_attributes_minus_bitpos (making the only caller that calls this function with bitpos != 0 go). In this testcase we want to access sth at offset 8 bytes, 0 bits but the memory model tells us the bitregion to consider is everything from offset 6 to offset 14 so instead of the correct initial mem (mem/j:HI (plus:SI (reg/f:SI 206) (const_int 8 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs S2 A32]) (with 4 byte alignemnt!) we create (mem/j:BLK (plus:SI (reg/f:SI 206) (const_int 6 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs+-6 S8 A32]) where the alignment is bogus. Thus, given the above general MEM_OFFSET analysis I'd say the following (ontop of my previous patch) should fix things more correctly: Index: gcc/expr.c === --- gcc/expr.c (revision 195014) +++ gcc/expr.c (working copy) @@ -4669,7 +4669,7 @@ expand_assignment (tree to, tree from, b || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE) { enum machine_mode mode1; - HOST_WIDE_INT bitsize, bitpos; + HOST_WIDE_INT bitsize, bitpos, bitpos_adj; unsigned HOST_WIDE_INT bitregion_start = 0; unsigned HOST_WIDE_INT bitregion_end = 0; tree offset; @@ -4683,9 +4683,15 @@ expand_assignment (tree to, tree from, b tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); + bitpos_adj = 0; if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) - get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset); + { + HOST_WIDE_INT orig_bitpos = bitpos; + get_bit_range (bitregion_start,
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:49:44 UTC --- Thanks Mikael. Having the testresults for -m32 and -m64 is also nice, by the way. And they indeed look very good! Philip's latest testsuite results look decent but worse. Some of those fails are definitely more convenient than Comment #14, because they don't include anything. We should figure out whether Philip is seeing something like an individual miscompilation in a determinant place, like in crtstuff.c, or many different problems.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:52:07 UTC --- Philip, from http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html seems obvious that Mikael is simply fetching with subversion and building.
[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-09 Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:56:03 UTC --- Thanks Daniel, don't worry I'm not going to close anything for now. But we should really clarify in PR41933 that the issue isn't about C++11 proper.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #22 from philip.copeland at oracle dot com 2013-01-09 10:59:13 UTC --- Ok so he's using 4.7.3 not 4.7.2-(butched by fedora folk) (there's about 24 patchs they apply) ugh,.. what would you like me to do here then? pull over 4.7.3.svn and give that a spin? Phil =--=
[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 10:59:54 UTC --- Daniel, are you sure PR41933 isn't C++11 proper? I gather that the corresponding Core issue (which at the time Jason also referenced) went into CD2, thus isn't just C++11?!?
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 11:07:10 UTC --- Oh well, testing the current vanilla 4_7-branch is always a good idea, if you ask me. That said, it seems very unlikely that back in the 4.7.2 times something such basic as your reduced Comment #14 could not work (it's the C++ Hello World!, literally!). Well, we could also bootstrap vanilla 4.7.2 and see what happens.
[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 11:26:10 UTC --- (In reply to comment #8) Or more correct Index: gcc/emit-rtl.c === --- gcc/emit-rtl.c (revision 195014) +++ gcc/emit-rtl.c (working copy) @@ -1839,7 +1839,12 @@ set_mem_attributes_minus_bitpos (rtx ref if (!align_computed) { - unsigned int obj_align = get_object_alignment (t); + unsigned int obj_align; + unsigned HOST_WIDE_INT obj_bitpos; + get_object_alignment_1 (t, obj_align, obj_bitpos); + obj_bitpos = (obj_bitpos + apply_bitpos) (obj_align - 1); And actually obj_bitpos = (obj_bitpos - apply_bitpos) (obj_align - 1); + if (obj_bitpos != 0) + obj_align = (obj_bitpos -obj_bitpos); attrs.align = MAX (attrs.align, obj_align); } }
[Bug middle-end/55882] [4.7/4.8 Regression] unaligned load/store : incorrect struct offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 11:35:33 UTC --- (In reply to comment #10) Eric, I am double-checking my patch and I believe all this 'bitpos' handling in set_mem_attributes_minus_bitpos (and/or MEM_OFFSET in general) looks suspicious. /* For a MEM rtx, the offset from the start of MEM_EXPR. */ #define MEM_OFFSET(RTX) (get_mem_attrs (RTX)-offset) I read from this that the XEXP (RTX, 0) points to MEM_EXPR + MEM_OFFSET (if MEM_OFFSET_KNOWN_P, and if !MEM_OFFSET_KNOWN_P we don't know how XEXP (RTX, 0) and MEM_EXPR relate). Now, in expand_assignment we do tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset); ... to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE); ... offset it with variable parts from 'offset' ... set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos); but bitpos here is _not_ ontop of 'to' but extracted from 'to' (and eventually modified by get_bit_range which may shift things to 'offset'). The only 'bitpos' that should be passed to set_mem_attributes_minus_bitpos is one that reflects - in the bitfield access case - that we actually access things at a different position. But at this point we don't know what optimize_bitfield_assignment_op or store_field will eventually do. Also MEM_OFFSET is in bytes while I believe 'bitpos' can end up as an actual bit position, so /* If we modified OFFSET based on T, then subtract the outstanding bit position offset. Similarly, increase the size of the accessed object to contain the negative offset. */ if (apply_bitpos) { gcc_assert (attrs.offset_known_p); attrs.offset -= apply_bitpos / BITS_PER_UNIT; if (attrs.size_known_p) attrs.size += apply_bitpos / BITS_PER_UNIT; } (whatever this comment means). I believe my fix is correct following the MEM_OFFSET description and guessing at what the argument to set_mem_attributes_minus_bitpos means by looking at its use. But I believe that expand_assignment should pass zero as bitpos to set_mem_attributes_minus_bitpos (making the only caller that calls this function with bitpos != 0 go). In this testcase we want to access sth at offset 8 bytes, 0 bits but the memory model tells us the bitregion to consider is everything from offset 6 to offset 14 so instead of the correct initial mem (mem/j:HI (plus:SI (reg/f:SI 206) (const_int 8 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs S2 A32]) (with 4 byte alignemnt!) we create (mem/j:BLK (plus:SI (reg/f:SI 206) (const_int 6 [0x6])) [0 dmfe[i_1].use_alt_rd_dqs+-6 S8 A32]) where the alignment is bogus. Thus, given the above general MEM_OFFSET analysis I'd say the following (ontop of my previous patch) should fix things more correctly: Index: gcc/expr.c === --- gcc/expr.c (revision 195014) +++ gcc/expr.c (working copy) @@ -4669,7 +4669,7 @@ expand_assignment (tree to, tree from, b || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE) { enum machine_mode mode1; - HOST_WIDE_INT bitsize, bitpos; + HOST_WIDE_INT bitsize, bitpos, bitpos_adj; unsigned HOST_WIDE_INT bitregion_start = 0; unsigned HOST_WIDE_INT bitregion_end = 0; tree offset; @@ -4683,9 +4683,15 @@ expand_assignment (tree to, tree from, b tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); + bitpos_adj = 0; if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) - get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset); + { + HOST_WIDE_INT orig_bitpos = bitpos; + get_bit_range (bitregion_start, bitregion_end, +to, bitpos, offset); + bitpos_adj = orig_bitpos - bitpos; + } /* If we are going to use store_bit_field and extract_bit_field, make sure to_rtx will be safe for multiple use. */ @@ -4839,7 +4845,7 @@ expand_assignment (tree to, tree from, b DECL_RTX of the parent struct. Don't munge it. */ to_rtx = shallow_copy_rtx (to_rtx); - set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos); + set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos_adj); /* Deal with volatile and readonly fields. The former is only done for MEM. Also
[Bug target/16350] gcc only understands little endian ARM systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350 Sam Thursfield sam.thursfield at codethink dot co.uk changed: What|Removed |Added CC||sam.thursfield at codethink ||dot co.uk --- Comment #30 from Sam Thursfield sam.thursfield at codethink dot co.uk 2013-01-09 11:36:46 UTC --- I hit this bug trying to build a GCC 4.6.2 that defaulted to ARMv7-a big-endian. Correct code would only be produced if -mbig-endian was passed during linking so that the --be8 flag was passed to the linker, but this meant that the compiler on my target system defaulted to producing code that didn't work on the target system -- not pretty. This particular issue has been fixed in 4.7.3 and later, however: 2012-07-25 Bharathi Seshadri bsesh...@cisco.com Jim Wilson jimwi...@cisco.com * config/arm/bpabi.h (BE8_LINK_SPEC): Set according to TARGET_BIG_ENDIAN_DEFAULT. From http://gcc.gnu.org/git/gcc.git: commit c6e19dd6c296449f6d9e54d630f8198acf103d24 Author: wilson wilson@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Jul 25 20:13:46 2012 + Pass -be8 by default for armv7-a when configured big-endian. config/arm/bpabi.h (BE8_LINK_SPEC): Set according to TARGET_BIG_ENDIAN_DEFAULT. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189867 138bc75d-0d04-0410-961f-82ee72b054a4 Backporting this patch to 4.6.2 means that I now have a compiler that produces correct code just from appending eb to the CPU in the target triplet and configuring GCC with the correct --with-arch= flag.
[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-09 11:37:49 UTC --- (In reply to comment #4) You are right, I missed the CD2 tag
[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55911 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 11:38:03 UTC --- Important note: I can reproduce the Segmentation fault way back to 4_5-branch, in other terms, whatever it is, happened also with the old implementation very close to the TR1 containers.
[Bug target/16350] gcc only understands little endian ARM systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350 --- Comment #31 from Sam Thursfield sam.thursfield at codethink dot co.uk 2013-01-09 11:46:59 UTC --- Ignore the comment about GCC 4.7.3, which doesn't even exist. Looks like the fix is only in trunk so far.
[Bug fortran/55916] New: Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 Bug #: 55916 Summary: Alignment issues with real(16) on i686 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org The following testcase with -m32 -msse4 -g -O3 -fno-inline may segfault (depending on whether malloc returns just 8-byte or 16-byte aligned pointer). real(16), allocatable :: (:) real(16) :: x(10) integer :: i,n=10 allocate((n)) do i = 1,n (i) = 8.0 enddo call foo () deallocate() contains subroutine foo () real(16), allocatable :: (:) (1) = (1) + 1 end subroutine end The problem is that __float128 aka real(16) has alignment 128 bits, but on i686-linux malloc only guarantees 64 bit alignment (2 * sizeof (void *) byte alignment). As __float128 is outside of the scope of C/C++, this is not a bug on the C library side. Guess for real(16) allocatables or any allocatables that require alignment bigger than that of standard types Fortran should use posix_memalign (or perhaps some libgfortran wrapper) that will be passed not just the size to allocate, but also required alignment.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-09 11:51:22 UTC --- #1 0xf80100490988 in __cxxabiv1::__cxa_get_globals () at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 63 { return get_global(); } (gdb) disassemble Dump of assembler code for function __cxxabiv1::__cxa_get_globals(): 0xf80100490960 +0: save %sp, -176, %sp 0xf80100490964 +4: sethi %hi(0), %o0 0xf80100490968 +8: sethi %hi(0), %i0 0xf8010049096c +12:sethi %hi(0x18f400), %l7 0xf80100490970 +16:call 0xf8010048dce0 __sparc_get_pc_thunk.l7 0xf80100490974 +20:add %l7, 0x290, %l7! 0x18f690 0xf80100490978 +24:add %o0, 8, %o0 0xf8010049097c +28:xor %i0, 0, %i0 0xf80100490980 +32:call 0xf8010061a558 0xf80100490984 +36:add %l7, %o0, %o0 = 0xf80100490988 +40:add %o0, %i0, %i0 0xf8010049098c +44:rett %i7 + 8 0xf80100490990 +48:nop Here's the disassembly for a working version of the compiler: Dump of assembler code for function __cxxabiv1::__cxa_get_globals(): 0xf801001ea7a0 +0: save %sp, -176, %sp 0xf801001ea7a4 +4: sethi %hi(0xc00), %o0 0xf801001ea7a8 +8: sethi %hi(0), %i0 0xf801001ea7ac +12:sethi %hi(0x129800), %l7 0xf801001ea7b0 +16:call 0xf80100182e60 __sparc_get_pc_thunk.l7 0xf801001ea7b4 +20:add %l7, 0x50, %l7 ! 0x129850 = 0xf801001ea7b8 +24:add %o0, 0x140, %o0 0xf801001ea7bc +28:xor %i0, 0x10, %i0 0xf801001ea7c0 +32:call 0xf80100317c20 __tls_get_addr@plt 0xf801001ea7c4 +36:add %l7, %o0, %o0 0xf801001ea7c8 +40:add %o0, %i0, %i0 0xf801001ea7cc +44:rett %i7 + 8 0xf801001ea7d0 +48:nop So it looks like the dynamic linker screwed up the PLT on your system. I think that you should rebuild the compiler without --enable-initfini-array.
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-09 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 11:55:09 UTC --- Or inline the re-alignment code (and allocate one more element). That will allow for the most optimization opportunities. posix_memalign unfortunately has a weird enough interface that we can't easily extract alignment for the pointer.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 12:06:53 UTC --- (In reply to comment #3) type :: t procedure(a), pointer, nopass :: p end type type(t) :: x procedure(iabs), pointer :: pp x%p = a ! ok [A] I believe that this is invalid because the interfaces do not match procedure(iabs), pointer = integer pointer procedure (integer formal) [...] x%p = a(1) ! invalid, but not rejected by 4.8 [B] This is valid: procedure(iabs), pointer = pointer to integer procedure(iabs) Huh? the interface of `x%p' is `a', not `iabs'. I think the comments are correct; the former is valid, the latter invalid.
[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55911 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 12:15:39 UTC --- This is invalid if size() bucket_count(), which is very likely: for (size_t i = 0; i umap.size(); i++) { const size_t bs = umap.bucket_size (i); Shouldn't the loop condition be i umap.bucket_count() instead?
[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55911 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 12:16:51 UTC --- Debug Mode even catches it: unordered_map:max_size: 576460752303423487 unordered_map:size: 10352716 unordered_map:bucket_count: 218971 unordered_map: load_factor: 47.278938 unordered_map: max_load_factor: 50.00 /home/wakelj/tools/Linux-f12-x86_64/4.8/include/c++/4.8.0/debug/unordered_map:229: error: attempt to access container with out-of-bounds bucket index 218971, container only holds 218971 buckets. Objects involved in the operation: sequence this @ 0x0x7fffd8ae2810 { type = NSt7__debug13unordered_mapIld11HashPtrdiffSt8equal_toIlESaIlEEE; } Aborted (core dumped)
[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55911 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 12:19:11 UTC --- When load_factor 1 there will be more than 1 element in some buckets, implying fewer buckets than elements, so the loop accesses non-existent buckets. When load_factor==1 the bucket_count() == size() so the loop succeeds (but is still potentially wrong because the load_factor is only the *average* number of elements per bucket.)
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #25 from philip.copeland at oracle dot com 2013-01-09 12:21:19 UTC --- Mmm yes I did notice the x86_64 trace I did bounced off into the tls/PLT area Breakpoint 1, __cxxabiv1::__cxa_get_globals () at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 63 { return get_global(); } (gdb) stepi 0x00354f25e1a7 63 { return get_global(); } (gdb) stepi 0x00354f25a3f0 in __tls_get_addr@plt () from /lib64/libstdc++.so.6 (gdb) stepi 0x00354f25a3f6 in __tls_get_addr@plt () from /lib64/libstdc++.so.6 (gdb) stepi 0x00354f25a3fb in __tls_get_addr@plt () from /lib64/libstdc++.so.6 (gdb) stepi 0x00354f258ff0 in ?? () from /lib64/libstdc++.so.6 where as the sparc went pretty much nowhere 8/ Ok,.. I was mid compiling 4.7.3 but it's a little more convenient to quickly change 4.7.2-8 as you suggest and give that a quick check,.. should take a few hours to get that far. I'll update in mm ~3-4 hours I guess Thanks Mikael, as reference was your version of 4.7.3 compiled without --enable-initfini-array ?
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2013-01-09 12:25:43 UTC --- (In reply to comment #1) posix_memalign unfortunately has a weird enough interface that we can't easily extract alignment for the pointer. Is it just because it outputs through a pointer? Are aligned_alloc, memalign and others easier then?
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-09 12:30:50 UTC --- Created attachment 29119 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29119 Testcase for bitfield and type-packing This first testcase checking pack-pragma for x64/x86 MS-struct layout. I got this testcase verified by a VC user. It was verified with VC10, VC11, and (Nov2012_CTP). (Btw no regression with my suggested patch applied).
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #26 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 12:42:13 UTC --- (In reply to comment #19) Mikael, could you compare against the versions of packages that I'm using? Well, my environment is Fedora 15 so all system components are older. glibc is 2.13.90-4.1 for instance. The other things that matter for gcc are newer and compiled and installed privately by myself: gmp-5.0.5, mpfr-3.1.1, mpc-1.0.1, binutils-2.22, all compiled by my own gcc-4.6.3. Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT patches that the fc* packages normally gets added, applied? That was with unmodified FSF sources (a weekly svn snapshot tarball). Note that RH's gcc src rpms are usually (always?) based on RH's own gcc branches (see http://gcc.gnu.org/viewcvs/branches/redhat/) rather than vanilla upstream releases or snapshots, so the amount of modifications are much larger than what the explicit set of patches indicate.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #27 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 12:46:11 UTC --- (In reply to comment #25) Mikael, as reference was your version of 4.7.3 compiled without --enable-initfini-array ? Yes.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 13:07:31 UTC --- (In reply to comment #4) (In reply to comment #3) snip Huh? the interface of `x%p' is `a', not `iabs'. I think the comments are correct; the former is valid, the latter invalid. Quite right - thanks, Mikael. I missed/forgot/ignored the first interface. That makes life a lot easier because the patch does the right thing :-) Cheers Paul
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #19 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 13:16:59 UTC --- (In reply to comment #18) (In reply to comment #17) (In reply to comment #16) Question is: Is the packing needed here? I would guess that it isn't. Of course I might be wrong here. After all, array_t3_ptr is a pointer, so it's not guaranteed to be contiguous, right? To answer that myself, I think the packing is indeed needed here. In fact this is exactly the case of comment 0. So, yes, we definitely need the packing! Dear Janus, R156749 was clearly an optimization too far. As far as correct code generation is concerned, you cannot have too many PACKs. Therefore, I would apply your regression fix, even if you are worried that it over-does it. Cheers Paul
[Bug libstdc++/55917] New: Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Bug #: 55917 Summary: Impossible to find/debug unhandled exceptions in an std::thread Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tob...@ringis.se If an unhandled exception occurs in an std::thread, the stack is unwound before std::terminate is called, which makes it impossible to find the location of the exception. I emailed gcc-help about this about a year ago, and learned that a fix was supposed to be applied for 4.7, but that fix didn't work out. Here's my post: http://gcc.gnu.org/ml/gcc-help/2011-11/msg00140.html The reason for the unwound stack is that libstdc++'s function that calls the user's thread function contains a try/catch all statement. The supposed fix was to use noexcept on the internal thread main function, and the reason why it did not work out is described here: http://gcc.gnu.org/ml/gcc-help/2013-01/msg00068.html I've tested 4.6, 4.7 and a 4.8 snapshot with identical results. See the attached test program tmp4.cpp. Compile with: g++ -std=c++0x -g tmp4.cpp -lpthread Run in gdb: ~ gdb a.out [...] (gdb) r Starting program: /home/tobias/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library /lib64/libthread_db.so.1. [New Thread 0x77fd0700 (LWP 10278)] terminate called after throwing an instance of 'std::runtime_error' what(): foo Program received signal SIGABRT, Aborted. [Switching to Thread 0x77fd0700 (LWP 10278)] 0x00318f036285 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-24.fc16.9.x86_64 libgcc-4.6.3-2.fc16.x86_64 libstdc++-4.6.3-2.fc16.x86_64 (gdb) bt #0 0x00318f036285 in raise () from /lib64/libc.so.6 #1 0x00318f037b9b in abort () from /lib64/libc.so.6 #2 0x0031964bbc5d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6 #3 0x0031964b9e16 in ?? () from /usr/lib64/libstdc++.so.6 #4 0x0031964b9e43 in std::terminate() () from /usr/lib64/libstdc++.so.6 #5 0x003196470b0b in ?? () from /usr/lib64/libstdc++.so.6 #6 0x00318fc07d90 in start_thread () from /lib64/libpthread.so.0 #7 0x00318f0f119d in clone () from /lib64/libc.so.6 (gdb) As you can see, neither the thread's main function, nor foo() is in the backtrace.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #1 from Tobias Ringström tobias at ringis dot se 2013-01-09 13:22:52 UTC --- Created attachment 29120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29120 Test program to illustrate the problem
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 13:30:27 UTC --- (In reply to comment #2) (In reply to comment #1) posix_memalign unfortunately has a weird enough interface that we can't easily extract alignment for the pointer. Is it just because it outputs through a pointer? Are aligned_alloc, memalign and others easier then? Yes.
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-09 13:34:07 UTC --- Created attachment 29121 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29121 Testcase for bitfield and structure-aligning via attribute This testcase use aligned/align attribute instead of #pragma pack. With suggested patch applied no regressions to VC results.
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-09 13:37:13 UTC --- Created attachment 29122 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29122 Testcase for bitfield and structure field-aligning by attribute By this testcase we validate that structure's member-alignment set by attribute is applied. With applied patch this test shows no regressions to VC compiled variant.
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 13:38:12 UTC --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) posix_memalign unfortunately has a weird enough interface that we can't easily extract alignment for the pointer. Is it just because it outputs through a pointer? Are aligned_alloc, memalign and others easier then? Yes. We can of course apply the same trick as we do for sincos - transform it to ({ void *tem; int ret; tem = __builtin_gcc_posix_memalign (res, alignment, size); *memptr = tem; ret; }) and then expand it to RTL as posix_memalign using another memory temporary ... The issue with such return is that we cannot see all possible uses of the return-by-reference value which is easy to do if it is the actual return value. Possibly an alloc_align attribute would be useful as well.
[Bug c++/55918] New: Stack partially unwound when noexcept causes call to std::terminate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918 Bug #: 55918 Summary: Stack partially unwound when noexcept causes call to std::terminate Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tob...@ringis.se Created attachment 29123 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29123 Test program to illustrate the problem When a noexcept function is violated, std::terminate is called. While the standard allows for the stack to be fully unwound, partially unwound, or not unwound at all, it is impossible to find the location where the exception was thrown, unless the stack is left unwound. GCC currently leaves the stack unwound in most cases, but in a very common case, which is illustrated by the attached example program, the stack is partially unwound. If the noexcept is removed to allow the exception to propagate all the way past main, std::terminate is called with the stack fully unwound, so it seems that GCC is able to do what I want. It would be highly desirable for the noexcept case to work in the same way as the unhandled exception case. # g++ -std=c++0x -g tmp3.cpp # gdb a.out [...] (gdb) bt #0 0x00318f036285 in raise () from /lib64/libc.so.6 #1 0x00318f037b9b in abort () from /lib64/libc.so.6 #2 0x0031964bbc5d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6 #3 0x0031964b9e16 in ?? () from /usr/lib64/libstdc++.so.6 #4 0x0031964b8e49 in ?? () from /usr/lib64/libstdc++.so.6 #5 0x0031964b973d in __gxx_personality_v0 () from /usr/lib64/libstdc++.so.6 #6 0x00319000f6fb in ?? () from /lib64/libgcc_s.so.1 #7 0x00319000fb58 in _Unwind_Resume () from /lib64/libgcc_s.so.1 #8 0x00400911 in level2 () at tmp3.cpp:16 #9 0x0040091a in level1 () at tmp3.cpp:20 #10 0x00400925 in main () at tmp3.cpp:24 As you can see, bad_guy is not in the backtrace. There are two simple modifications that makes the backtrace complete. The first is to remove the noexcept from level1, and the second is to remove the Foo declaration in level2 (or delete Foo's destructor).
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 13:44:35 UTC --- As I said at http://gcc.gnu.org/ml/gcc-help/2013-01/msg00068.html this can't be changed for std::thread, see http://gcc.gnu.org/ml/libstdc++/2012-12/msg00062.html and the patch at http://gcc.gnu.org/ml/libstdc++/2012-12/msg00068.html for discussion and code that absolutely requires exceptions of type __forced_unwind to be able to escape the thread start function, otherwise thread cancellation crashes the program, which is not acceptable. If the function is not noexcept then it must catch exceptions to ensure std::terminate is called as required, and catching the exception causes the stack to be unwound. So it's difficult do anything about std::thread. Please open a separate bug (with Component=c++) for the http://gcc.gnu.org/ml/gcc-help/2013-01/msg00058.html issue when noexcept interacts with a destructor on the stack. That applies to code not using std::thread too.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 13:48:04 UTC --- Ah, I se PR 55918 - thanks!
[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-09 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 13:52:18 UTC --- I guess Jason can say whether this is a bug in the current behaviour or if your request should be severity=enhancement, but at the very least we need to document the intended behaviour at http://gcc.gnu.org/onlinedocs/gcc/Exception-handling.html
[Bug fortran/53537] [4.6/4.7/4.8 Regression] Explicit IMPORT of renamed USE-associated symbol fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53537 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 13:54:15 UTC --- Created attachment 29124 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29124 Fix for the regression in comment #3 For the remaining problem: (In reply to comment #3) The patch of comment 1 fails for testsuite/gfortran.dg/import7.f90: TYPE(T3) X 1 Error: The type of 'x' at (1) has not been declared within the interface maybe we can just remove the error. After all, there is already non-interface-specific code to diagnose uses of undeclared types. For that code to trigger in place of the error above, a few adjustments are needed to avoid searching the type outside the interface (so that the type is really not found). With the attached patch, comment #0, comment #1 and comment #4 are accepted, but a few adjustments are needed in the testsuite: from: type(fcnparms) :: fparams ! { dg-error not been declared within the in 1 Error: The type of 'fparams' at (1) has not been declared within the interface to: type(fcnparms) :: fparams ! { dg-error not been declared within the in 1 Error: Derived type 'fcnparms' at (1) is being used before it is defined I will test the patch against the full testsuite. As it touches the core of the symbol resolution, it's quite to be expected that it has interesting side effects.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 13:59:58 UTC --- One option would be to make the start function have a dynamic-exception-specification of throw(__cxxabiv1::__forced_unwind), which would allow the cancellation exception to propagate (as required) but prevent any other exceptions, but that would result in a call to std::unexpected() rather than std::terminate(), and a user could have replaced the unexpected_handler, so we would not be able to meet the requirement that std::terminate() is called. On top of that, I think the stack would still get unwound before the call to std:unexpected, and dynamic-exception-specifications and unexpected handlers are deprecated in C++11. So I don't think we want to do that. My inclination is to close this as WONTFIX.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #5 from Tobias Ringström tobias at ringis dot se 2013-01-09 14:06:08 UTC --- Yes, I thought two reports were in order, as they are only vaguely related. To me, this one is the most important problem. I struggle to understand how I can be the first to have this problem. Surely it must be an enormous problem if you use std::thread? I'm working on a somewhat large multi-threaded program, and if there's an exception anywhere, e.g. a failed range-check in a container, it's *completely impossible* to find the problem in a debugger. We've now switched to boost::thread instead because it does not have this problem. I must say that I'm very surprised that you call it an enhancement, and that you consider closing it as WONTFIX, seeing how the current behavior is so mindbogglingly unfriendly. There is a reason why GCC does not unwind the stack for non-threaded unhandled exceptions. Perhaps std::thread is not widely used yet, or I'm the only one with buggy code?
[Bug fortran/55919] New: [4.8 Regression] Bogus warning with -J directory/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55919 Bug #: 55919 Summary: [4.8 Regression] Bogus warning with -J directory/ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: tkoe...@gcc.gnu.org Found at https://groups.google.com/d/topic/comp.lang.fortran/G6XGIE-lwuk/discussion The following code in scanner.c's add_path_to_list triggers a bogus warning under Windows, if a dirname ends in a '/' or a '\\': if (stat (p, st)) { if (errno != ENOENT) gfc_warning_now (Include directory \%s\: %s, path, xstrerror(errno)); else { /* FIXME: Also support -Wmissing-include-dirs. */ if (warn) gfc_warning_now (Nonexistent include directory \%s\, path); } Note that the macro IS_DIR_SEPARATOR can be used to check for / and \. By the way, one should take the opportunity and add support for Wmissing-include-dirs. Cf. PR 55534.
[Bug fortran/55919] [4.8 Regression] Bogus warning with -J directory/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55919 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-09 14:14:43 UTC --- Forgot to add a cross-ref: The warning was added 2012-08-02 for PR 54033. (That PR is still not closed as fixed).
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 --- Comment #3 from Fanael fanael4 at gmail dot com 2013-01-09 14:19:09 UTC --- (In reply to comment #2) Are you sure that you do not somehow pull in LTO objects from older releases? Yes, happens even with -nostdlib, even on builds where I'm absolutely sure there's no way an old LTO object could sneak in.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-09 14:26:22 UTC --- I've just got back from the holidays, I will take a look probably on Friday. David's analysis hints that the scheduler should treat the insn as unique (i.e. it is cannot be copied) but fails to do so.
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.4 --- Comment #39 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 14:29:31 UTC --- Fixed for 4.6.4 4.7.3 4.8.0. Thanks for the bug report.
[Bug fortran/45836] [OOP] Type Bound Procedure Error - Type Mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45836 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.4 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 14:31:53 UTC --- Fixed for 4.6.4 4.7.3 4.8.0. Thanks for the bug report.
[Bug fortran/45900] [OOP] Static TBP resolved incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45900 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.4 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 14:32:41 UTC --- Fixed for 4.6.4 4.7.3 4.8.0. Thanks for the bug report.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 14:42:00 UTC --- (In reply to comment #5) Yes, I thought two reports were in order, as they are only vaguely related. To me, this one is the most important problem. I struggle to understand how I can be the first to have this problem. Surely it must be an enormous problem if you use std::thread? I'm working on a somewhat large multi-threaded program, and if there's an exception anywhere, e.g. a failed range-check in a container, it's *completely impossible* to find the problem in a debugger. If you're running in the debugger, rather than examining a core file post-mortem, you can use catch throw or break __cxa_throw to break when the exception is thrown. Otherwise you already know the workaround, put 'noexcept' on the function you pass to std::thread (which breaks pthread_cancel but if you're not using that it doesn't matter.) We've now switched to boost::thread instead because it does not have this problem. I must say that I'm very surprised that you call it an enhancement, The current implementation conforms to the standard. and that you consider closing it as WONTFIX, I've explained why it can't easily be changed, unless anyone has some idea I haven't thought of yet to preserve pthread_cancel behaviour and preserve the requirement that std::terminate() is called. seeing how the current behavior is so mindbogglingly unfriendly. There is a reason why GCC does not unwind the stack for non-threaded unhandled exceptions. The behaviour comes directly from the explicit requirement in the standard that an unhandled exception in a std::thread must call std::terminate. If it's guaranteed that an uncaught exception leaving that function will still call terminate, then the catch(...) block could be removed. Maybe I could do that conditionally for targets where it's known to work as required.
[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-01-09 14:42:54 UTC --- If you're looking for 'bad_guy' to be in the backtrace, that sounds to me like you want it to not be unwound at all, and I'm surprised that it doesn't already work that way.
[Bug c++/55801] ICE with thread_local after ill-formed forward declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55801 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-01-09 14:43:59 UTC --- Author: paolo Date: Wed Jan 9 14:43:50 2013 New Revision: 195050 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195050 Log: /cp 2013-01-09 Paolo Carlini paolo.carl...@oracle.com PR c++/55801 * decl2.c (var_needs_tls_wrapper): Return false when error_operand_p of the argument is true. /testsuite 2013-01-09 Paolo Carlini paolo.carl...@oracle.com PR c++/55801 * g++.dg/tls/thread_local-ice.C: New. Added: trunk/gcc/testsuite/g++.dg/tls/thread_local-ice.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55801] ICE with thread_local after ill-formed declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55801 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 Summary|ICE with thread_local after |ICE with thread_local after |ill-formed forward |ill-formed declaration |declaration | --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 14:45:42 UTC --- Fixed for 4.8.0.
[Bug libstdc++/55911] Segfault in unordered_map with max_load_factor 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55911 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 14:47:12 UTC --- Thanks Jon.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #28 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 14:50:16 UTC --- Thanks Eric for following this.
[Bug c/48418] [4.6/4.7/4.8 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 14:51:17 UTC --- Author: jakub Date: Wed Jan 9 14:51:09 2013 New Revision: 195051 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195051 Log: PR c/48418 * c-common.c (c_fully_fold_internal): Warn for LSHIFT_EXPR and RSHIFT_EXPR, if orig_op1 isn't INTEGER_CST, op1 is INTEGER_CST and is either negative or bigger or equal to type precision of the first operand. * typeck.c (cp_build_binary_op): For LSHIFT_EXPR and RSHIFT_EXPR, call maybe_constant_value for the negative or too big shift count warnings. * c-c++-common/pr48418.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr48418.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/48418] [4.6/4.7 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Bit |Bit shift operator = |shift operator = --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 15:03:09 UTC --- Warning regression fixed for 4.8+ for now.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 15:10:55 UTC --- Author: hubicka Date: Wed Jan 9 15:10:43 2013 New Revision: 195054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195054 Log: PR tree-optimiation/55875 * gcc.c-torture/execute/pr55875.c: New testcase. * g++.dg/torture/pr55875.C: New testcase. * tree-ssa-loop-niter.c (number_of_iterations_cond): Add EVERY_ITERATION parameter. (number_of_iterations_exit): Check if exit is executed every iteration. (idx_infer_loop_bounds): Similarly here. (n_of_executions_at_most): Simplify to only test for cases where statement is dominated by the particular bound; handle correctly the postdominance test. (scev_probably_wraps_p): Use max loop iterations info as a global bound first. Added: trunk/gcc/testsuite/g++.dg/torture/pr55875.C trunk/gcc/testsuite/gcc.c-torture/execute/pr55875.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 15:13:20 UTC --- Fixed, thanks.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #165 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 15:16:26 UTC --- OK, I tracked down the undefined reference to error: /tmp/cc0oq4BG.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc against '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer' which may overflow at runtime; recompile with -fPIC it is caused by bug in Mozilla - it includes file defininig virtual function that use '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer' (in SkPaint) but it never links with implementation. Normally the function is optimized out. It is not due to fact that we never optimize out virtual functions prior inlining for devirtualization and in WPA path we forget to remove these when done. Fixed by the following patch Index: ipa-inline.c === --- ipa-inline.c(revision 194916) +++ ipa-inline.c(working copy) @@ -1793,7 +1793,7 @@ } inline_small_functions (); - symtab_remove_unreachable_nodes (true, dump_file); + symtab_remove_unreachable_nodes (false, dump_file); free (order); /* Inline functions with a property that after inlining into all callers the Index: lto/lto.c === --- lto/lto.c (revision 194916) +++ lto/lto.c (working copy) @@ -3215,6 +3215,7 @@ cgraph_state = CGRAPH_STATE_IPA_SSA; execute_ipa_pass_list (all_regular_ipa_passes); + symtab_remove_unreachable_nodes (false, dump_file); if (cgraph_dump_file) { Index: cgraphclones.c === --- cgraphclones.c (revision 194916) +++ cgraphclones.c (working copy) @@ -184,6 +184,7 @@ new_node-symbol.decl = decl; symtab_register_node ((symtab_node)new_node); new_node-origin = n-origin; + new_node-symbol.lto_file_data = n-symbol.lto_file_data; if (new_node-origin) { new_node-next_nested = new_node-origin-nested;
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #166 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-09 15:19:41 UTC --- Markus, the apperance of undefined references I fixed by patch above is highly sensitive to partitioning and inlining decision. Can you, please, check if the problem with PGO remains? It may be another instance of the same issue.
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2013-01-09 15:23:54 UTC --- Let me look into those... Try the patch I attached to PR45375 Honza
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #29 from philip.copeland at oracle dot com 2013-01-09 15:29:26 UTC --- Rebuilt fedoras 4.7.2-8 gcc without --enable-initfini-array reinstalled in a chroot and rebuilt the test program bash-4.2# g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper Target: sparc64-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,lto --enable-plugin --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 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128 --with-cpu=ultrasparc --disable-multilib --build=sparc64-redhat-linux Thread model: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) bash-4.2# ./a.out we are able to write to stderr Segmentation fault (core dumped) Breakpoint 1, __cxxabiv1::__cxa_get_globals () at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63 63 { return get_global(); } (gdb) disassemble Dump of assembler code for function __cxxabiv1::__cxa_get_globals(): 0xf80100180960 +0: save %sp, -176, %sp 0xf80100180964 +4: sethi %hi(0), %o0 0xf80100180968 +8: sethi %hi(0), %i0 0xf8010018096c +12:sethi %hi(0x18f400), %l7 0xf80100180970 +16:call 0xf8010017db40 __sparc_get_pc_thunk.l7 0xf80100180974 +20:add %l7, 0x290, %l7! 0x18f690 = 0xf80100180978 +24:add %o0, 8, %o0 0xf8010018097c +28:xor %i0, 0, %i0 0xf80100180980 +32:call 0xf8010030a558 0xf80100180984 +36:add %l7, %o0, %o0 0xf80100180988 +40:add %o0, %i0, %i0 0xf8010018098c +44:rett %i7 + 8 0xf80100180990 +48:nop End of assembler dump. (gdb) stepi 0xf8010018097c 63 { return get_global(); } (gdb) 0xf80100180980 63 { return get_global(); } (gdb) 0xf80100180984 63 { return get_global(); } (gdb) 0xf8010030a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6 (gdb) Program received signal SIGSEGV, Segmentation fault. 0xf8010030a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6 again, no thread level support address actions. Moving on to rebuild of gcc-trunk (4.7.3?)
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-01-09 15:45:35 UTC --- Program received signal SIGSEGV, Segmentation fault. 0xf8010030a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6 Is /lib64/libstdc++.so.6 really the rebuilt library? Can you verify by running readelf -S on it that it doesn't contain .init_array and .fini_array sections?
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #31 from philip.copeland at oracle dot com 2013-01-09 16:00:56 UTC --- Hurm,... bash-4.2# cd /tmp bash-4.2# mkdir expand bash-4.2# cd expand/ bash-4.2# rpm2cpio /builddir/build/RPMS/libstdc++-4.7.2-8.fc18.sparc64.rpm | cpio -id bash-4.2# md5sum /tmp/expand/usr/lib64/libstdc++.so.6.0.17 /lib64/libstdc++.so.6 2b5b38c3e80e9739b1599df7e6ae84da /tmp/expand/usr/lib64/libstdc++.so.6.0.17 2b5b38c3e80e9739b1599df7e6ae84da /lib64/libstdc++.so.6 Well,.. it's definitely the rebuilt library and --enable-initfini-array is not part of the passed options anymore, however readelf -S shows that those sections still exist [18] .init_array INIT_ARRAY 001e6558 000e6558 0040 WA 0 0 8 [19] .fini_array FINI_ARRAY 001e6598 000e6598 0008 WA 0 0 8 ... [24] .plt PROGBITS 001ecc00 000ecc00 5820 0020 WAX 0 0 256 are there any of the options that I used that would reenable initfini-array?
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #32 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-09 16:07:19 UTC --- Well, if you don't pass anything an autoconf test tries to figure out: --enable-initfini-array Force the use of sections .init_array and .fini_array (instead of .init and .fini) for constructors and destructors. Option --disable-initfini-array has the opposite effect. If neither option is specified, the configure script will try to guess whether the .init_array and .fini_array sections are supported and, if they are, use them. I would quickly test passing an explicit --disable-initfini-array
[Bug fortran/55916] Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-09 16:09:25 UTC --- As __float128 is outside of the scope of C/C++, this is not a bug on the C library side. It might be outside the scope of C/C++ but doesn't C99 allow some implementation defined types?
[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792 --- Comment #19 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 16:11:06 UTC --- The BLOCK tree node is cleared by (gdb) bt #0 0x00336b4882ee in __memset_sse2 () from /lib64/libc.so.6 #1 0x00545fdf in clear_marks () at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815 #2 0x00546621 in ggc_collect () at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086 #3 0x008ad816 in execute_todo (flags=2102) at /export/gnu/import/git/gcc/gcc/passes.c:2023 #4 0x008ae175 in execute_one_pass (pass=0x17b9c70) at /export/gnu/import/git/gcc/gcc/passes.c:2349 #5 0x008ae2da in execute_pass_list (pass=0x17b9c70) at /export/gnu/import/git/gcc/gcc/passes.c:2383 #6 0x008ae30b in execute_pass_list ( pass=0x16d07e0 pass_all_optimizations) at /export/gnu/import/git/gcc/gcc/passes.c:2384 #7 0x005da366 in expand_function (node=0x716f5378) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641 #8 0x005da821 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745 #9 0x005db2ab in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043 #10 0x0053c60a in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390 #11 0x00999401 in compile_file () ---Type return to continue, or q return to quit--- at /export/gnu/import/git/gcc/gcc/toplev.c:545 #12 0x0099b3e4 in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1878 #13 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78) at /export/gnu/import/git/gcc/gcc/toplev.c:1954 #14 0x00fff958 in main (argc=28, argv=0x7fffdc78) at /export/gnu/import/git/gcc/gcc/main.c:36 (gdb) When we remap a block: static void remap_block (tree *block, copy_body_data *id) { tree old_block; tree new_block; /* Make the new block. */ old_block = *block; new_block = make_node (BLOCK); TREE_USED (new_block) = TREE_USED (old_block); BLOCK_ABSTRACT_ORIGIN (new_block) = old_block; BLOCK_SOURCE_LOCATION (new_block) = BLOCK_SOURCE_LOCATION (old_block); BLOCK_NONLOCALIZED_VARS (new_block) = vec_safe_copy (BLOCK_NONLOCALIZED_VARS (old_block)); *block = new_block; /* Remap its variables. */ BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block), BLOCK_NONLOCALIZED_VARS (new_block), id); we didn't register it with GC root.
[Bug target/5372] [powerpc-*-eabi] -mno-eabi not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5372 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool segher at gcc dot gnu.org 2013-01-09 16:14:11 UTC --- Still happens with current mainline.
[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55915 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |bootstrap Version|lto |4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-09 16:15:57 UTC --- --with-system-zlib You said zlib.h is included with the system but you don't update CXXFLAGS only CFLAGS.
[Bug fortran/55758] LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55758 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-09 16:20:42 UTC --- Author: burnus Date: Wed Jan 9 16:20:33 2013 New Revision: 195055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195055 Log: 2013-01-09 Tobias Burnus bur...@net-b.de PR fortran/55758 * resolve.c (resolve_symbol): Reject non-C_Bool logicals in BIND(C) procedures with -std=f*. 2013-01-09 Tobias Burnus bur...@net-b.de PR fortran/55758 * gfortran.dg/bind_c_bool_1.f90: New. * gfortran.dg/do_5.f90: Add dg-warning. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_bool_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/do_5.f90
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #12 from Jan Hubicka hubicka at ucw dot cz 2013-01-09 16:29:21 UTC --- Shall we track the C testcase regression in 4.7 and earlier? Honza
[Bug tree-optimization/55920] New: ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 Bug #: 55920 Summary: ICE in expand_debug_locations, at cfgexpand.c:3753 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com CC: mjam...@suse.cz Created attachment 29125 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29125 preprocessed src gcc version 4.8.0 20130109 (experimental) [trunk revision 195054] (GCC) Using arm-unknown-linux-gnueabi $ ./xgcc -B. -O2 -g ~/ice.i -c /home/ryan/ice.i: In function 'state_panic': /home/ryan/ice.i:32:6: warning: incompatible implicit declaration of built-in function 'memcpy' [enabled by default] memcpy (from, client-active-address.iabuf, sizeof from); ^ /home/ryan/ice.i:25:7: internal compiler error: in expand_debug_locations, at cfgexpand.c:3753 void state_panic (cpp) void *cpp; ^ 0x5e3584 expand_debug_locations ../../gcc/cfgexpand.c:3749 0x5e3584 gimple_expand_cfg ../../gcc/cfgexpand.c:4606 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Seems it was introduced in rev195015 http://gcc.gnu.org/viewcvs?view=revisionrevision=195015
[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55915 --- Comment #2 from Alexey Pavlov alexpux at gmail dot com 2013-01-09 16:31:18 UTC --- Do I need add include paths to CXXFLAGS? But I successfully build gcc-4.6.3 and 4.7.2 without add zlib include path to CXXFLAGS only to CFLAGS.
[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2013-01-09 16:33:02 UTC --- (In reply to comment #3) BTW, there is a slight inconsistency between the two patterns, the first pattern uses sselog1 type for both the unpckldp %0, %0 and %vmovddup %1, %0 and V2DFmode mode attribute, while the second pattern uses sselog type for both of those and DFmode mode attribute for the movddup case. Actually, the sselog/sselog1 difference is OK, it makes difference only in the calculation of memory attribute. By default, sselog looks at operand[2], which is missing when the pattern has only two operands. So, sselog1 (and all _1 types) looks at operand[1]. Regarding mode: length calculation depends on it, so for V2DF non-avx sse insns prefix_data16 is added, and for DF non-avx sse insn prefix_rep is added. While for sselog insns, V2DF vs. DF makes no difference in length, movddup uses prefix_rex, so the correct mode for movddup is DF. I will submit a trivial patch to change this inconsistency.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 16:35:13 UTC --- Yes, but I'd say under a different PR.
[Bug middle-end/55921] New: Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 Bug #: 55921 Summary: Crash in verify_ssa for asm to side-steps complex pessimization Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Created attachment 29126 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29126 testcase verify_ssa crashes during expand for a simple testcase that uses a pair of asms to avoid the tree pass pessimization of complex type data moves. Observed with GCC 4.7.0 i686-pc-linux-gnu X epiphany-elf, i686-pc-linux-gnu native Red Hat 4.7.2-2, and i686-pc-linux-gnu native 4.8.0 20130109 (experimental) (revision 195054) (gdb) run Starting program: /ssd/fsf/inst/libexec/gcc/i686-pc-linux-gnu/4.8.0/cc1 -fpreprocessed tc3.i -quiet -dumpbase tc3.c -mtune=generic -march=pentiumpro -auxbase tc3 -version -o tc3.s GNU C (GCC) version 4.8.0 20130109 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.8.0 20130109 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.8.0 20130109 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.8.0 20130109 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7fd55bd33553a03a09fb094c59fe563c Program received signal SIGSEGV, Segmentation fault. verify_ssa (check_modified_stmt=true) at ../../gcc/gcc/tree-ssa.c:942 942 if (!gimple_nop_p (stmt)) (gdb) bt #0 verify_ssa (check_modified_stmt=true) at ../../gcc/gcc/tree-ssa.c:942 #1 0x084c6fbe in execute_function_todo (data=data@entry=0x8001c) at ../../gcc/gcc/passes.c:1969 #2 0x084c7788 in do_per_function ( callback=0x84c6f20 execute_function_todo(void*), data=0x8001c) at ../../gcc/gcc/passes.c:1703 #3 0x084c78ba in execute_todo (flags=524316) at ../../gcc/gcc/passes.c:2001 #4 0x084cabff in execute_one_pass (pass=pass@entry=0x8dced80) at ../../gcc/gcc/passes.c:2321 #5 0x084cb035 in execute_pass_list (pass=0x8dced80) at ../../gcc/gcc/passes.c:2383 #6 0x0826186e in expand_function (node=0xb7be93f0) at ../../gcc/gcc/cgraphunit.c:1641 #7 0x08263bb4 in output_in_order () at ../../gcc/gcc/cgraphunit.c:1834 #8 compile () at ../../gcc/gcc/cgraphunit.c:2038 #9 0x08263f2a in finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:2120 #10 0x08137e45 in c_write_global_declarations () at ../../gcc/gcc/c/c-decl.c:10120 #11 0x0856d85d in compile_file () at ../../gcc/gcc/toplev.c:559 #12 0x0856f82c in do_compile () at ../../gcc/gcc/toplev.c:1878 #13 toplev_main (argc=13, argv=0xbfffeda4) at ../../gcc/gcc/toplev.c:1954 #14 0x0811a2cb in main (argc=13, argv=0xbfffeda4) at ../../gcc/gcc/main.c:36 (gdb) frame 0 #0 verify_ssa (check_modified_stmt=true) at ../../gcc/gcc/tree-ssa.c:942 942 if (!gimple_nop_p (stmt)) (gdb) p stmt $1 = (gimple_statement_d *) 0x0