[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 --- Comment #9 from Tobias Burnus 2011-04-06 06:53:53 UTC --- (In reply to comment #8) > My gcc4.5 and gcc4.4 apparently did not have libquadmath-support Yes, libquadmath is a new GCC 4.6 feature, cf. http://gcc.gnu.org/gcc-4.6/changes.html and http://gcc.gnu.org/onlinedocs/libquadmath/ -- While primarily added and used for gfortran, it also can be used with C/C++. On GLIBC systems, libquadmath has printf hooks, allowing one to use the __float128 directly in (s,sn,f,)printf. (On other systems, quadmath_snprintf has to be used.) > Not much can be done if the packages get it wrong. Thanks for the help. I'll > close the bug report. Thanks. (In terms of compatibility of older programs with newer "libgfortan"s, it is unfortunate. However, as the capabilities of the compiler are checked during the compilation of the library, it is difficult to avoid. Fortunately, it only affects SELECTED_REAL_KIND where the arguments are not known at compile time. -- The Fortran 2008 "workaround" is to use ISO_Fortran_env's REAL_KINDS, which gfortran supports since GCC 4.6 - but F2008 only and GCC since 4.6 does not make it really portable.)
[Bug regression/48477] New: [4.7 Regression]: gfortran.dg/coarray_13.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48477 Summary: [4.7 Regression]: gfortran.dg/coarray_13.f90 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: bur...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 23895 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23895 Reduced gfortran.dg/coarray_13.f90 exposing the failure This test previously passed, now it fails. Revision r171949 caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ... ... FAIL: gfortran.dg/coarray_13.f90 -O2 execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -g execution test The messages in gfortran.log are similar: PASS: gfortran.dg/coarray_13.f90 -O2 (test for excess errors) core: 4 byte write to unmapped address 0x10190 at 0x146 program stopped with signal 11. Author/committer of suspect revision CC:ed. Looking into this, I see badness in the form of a modified test-case. Multiple tests for new (or greatly improved) functionality were apparently added to an existing test-case. While that worked for the tested platform, it didn't work for cris-elf and I'd guess also some other unfortunate platform. So, because an existing test was modified rather than new tests added, it comes out as a regression. That's why existing test-cases should never be upgraded like that; they should be fixed only if they were actually wrong or just enough to maintain the intention of the test when gcc gets too smart. I'm adding a reduced test-case which fails at r172016; all but a single test and call to abort. Hopefully this is enough to spark some ideas as to the cause. I can assist with some target-specific testing; execution tracing etc. but note that the general instructions for building and running on a simulator toolchain apply to cris-elf. (For the record, at revision r171949 the tree was in a flux, with 52 regressions in total for cris-elf, but that's been resolved to this single regression at r172016. I tested r171943 (last regression-free revision before r171949) patched with the single commit of r171949; that combination also fails.)
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dongsheng Song changed: What|Removed |Added CC||dongsheng.song at gmail dot ||com --- Comment #55 from Dongsheng Song 2011-04-06 06:35:11 UTC --- (In reply to comment #54) > (In reply to comment #53) > > If I don't use LTO Optimization, Vadim Zeitlin's patch works well. > > But if I use LTO Optimization, the compiling speed becomes vey slow, and the > > linker stage fails. I will get the information: > > > > lto1.exe: out of memory allocating 1900552 bytes > > lto-wrapper: g++ returned 1 exit status > > ld.exe: lto-wrapper failed > > collect2: ld returned 1 exit status > > > > mingw32-make: *** [wxmsw28u_gcc.dll] Error 1 > > BTW, I use gcc 4.6. me too. If I use 32bit compiler on windows/Linux, target 32bit windows, single huge monolithic library build with or without LTO will out of memory, multiple libraries build failed with LTO, OK for without LTO.
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #2 from Daniel Krügler 2011-04-06 06:34:20 UTC --- (In reply to comment #1) I agree, I just recognize that 13.3.1.6 [over.match.ref] p. 1 b. 1 is written to support this: "The conversion functions of S and its base classes are considered, except that for copy-initialization, only the non-explicit conversion functions are considered. Those that are not hidden within S and yield type “lvalue reference to cv2 T2” (when 8.5.3 requires an lvalue result) or “cv2 T2” or “rvalue reference to cv2 T2” (when 8.5.3 requires an rvalue result), where “cv1 T” is reference-compatible (8.5.3) with “cv2 T2”, are candidate functions." IMO the core language should strike the reference to "implicit conversions" in 8.5.3.
[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 --- Comment #2 from Ira Rosen 2011-04-06 06:15:10 UTC --- Created attachment 23894 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23894 char_result_13.s
[Bug middle-end/48377] [4.6 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #8 from Dmitry Gorbachev
2011-04-06 05:25:21 UTC ---
In hashmap.hpp
static inline uint32_t
Hashcode( const char* s, uint32_t len, bool case_insensitive)
{
// prepare to run through string in 4-byte chunks
const uint32_t* wordp = (const uint32_t*)s;
bug: wordp can be incorrectly aligned.
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2011.04.06 04:08:17 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill 2011-04-06 04:08:17 UTC --- This seems to me like a wording issue, not a compiler bug. The use of "implicitly" in 8.5.3 should have been adjusted when explicit conversion operators went in; this should be reported as a core DR.
[Bug debug/47919] -fcompare-debug failure with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47919 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Depends on||47881, 47994 Resolution||FIXED --- Comment #4 from Alexandre Oliva 2011-04-06 03:11:49 UTC --- The second testcase was fixed by the patch for bug 47881.
[Bug libstdc++/48476] New: [C++0x] conversion between std::tuple which have reference member is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48476
Summary: [C++0x] conversion between std::tuple which have
reference member is rejected
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
Created attachment 23893
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23893
Proposed patch for libstdc++-v3/include/std/tuple.hpp
gcc-4.6.0 rejects this code (bug.cc):
-
#include
int main()
{
int i = 0;
std::tuple t = std::forward_as_tuple( i, 0 );
}
-
# g++ -std=c++0x bug.cc
In file included from bug.cc:1:0:
/usr/local/gcc46/lib/gcc/i686-pc-cygwin/4.6.0/../../../../include/c++/4.6.0/tuple:
In constructor 'std::_Head_base<_Idx, _Head, false>::_Head_base(_UHead&&) [with
_UHead = int, unsigned int _Idx = 0u, _Head = int&]':
/usr/local/gcc46/lib/gcc/i686-pc-cygwin/4.6.0/../../../../include/c++/4.6.0/tuple:183:35:
instantiated from 'std::_Tuple_impl<_Idx, _Head, _Tail
...>::_Tuple_impl(std::_Tuple_impl<_Idx, _UElements ...>&&) [with _UElements =
{int&, int&&}, unsigned int _Idx = 0u, _Head = int&, _Tail = {int}]'
/usr/local/gcc46/lib/gcc/i686-pc-cygwin/4.6.0/../../../../include/c++/4.6.0/tuple:343:60:
instantiated from 'std::tuple<_T1, _T2>::tuple(std::tuple<_U1, _U2>&&) [with
_U1 = int&, _U2 = int&&, _T1 = int&, _T2 = int]'
bug.cc:6:57: instantiated from here
/usr/local/gcc46/lib/gcc/i686-pc-cygwin/4.6.0/../../../../include/c++/4.6.0/tuple:101:42:
error: invalid initialization of non-const reference of type 'int&' from an
rvalue of type 'int'
-
I found a conversion ctor of '_Tuple_impl<_Idx, _Head, _Tail...>',
-
// libstdc++-v3/include/std/tuple.hpp, line 180
template
_Tuple_impl(_Tuple_impl<_Idx, _UElements...>&& __in)
: _Inherited(std::move(__in._M_tail())),
_Base(std::move(__in._M_head())) { }
-
is wrong, when the first type of '_UElements...' is lvalue reference.
It should be implemented with std::forward, not std::move, like this:
-
template
_Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
: _Inherited(std::move(__in._M_tail())),
_Base(std::forward<_UHead>(__in._M_head())) { }
-
and it would be work better.
And I found these kinds of bugs also appear in implementations of
assignment-ops
and std::tuple_cat, so I attach a brief patch to fix them ( it might have
some problems, because I have not tested it enough ).
I'm glad if it could be some help.
[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 Scot Breitenfeld changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Scot Breitenfeld 2011-04-06 01:36:28 UTC --- (In reply to comment #7) > (In reply to comment #3) I've played around with going between gcc 4.6, 4.5 and 4.4 and indeed it fixes the problem if you make sure to specify the correct LD_LIBRARY_PATH to the matching gcc version. For example, if I'm using gfortran4.6 then the library path LD_LIBRARY_PATH needs to find libgfortran.so at the installed 4.6 library path, for example /usr/local/lib/gcc46/. I did this for the test program and it works. It gave KIND=4,8,10,16 so gcc46 must of had libquadmath-support, and a program with KIND=16 compiles. My gcc4.5 and gcc4.4 apparently did not have libquadmath-support, so the test program gives KIND=4,8,10 which is fine. I also verified I could use the LD_LIBRARY_PATH at gcc4.5 for gcc4.4, so they are backward compatible assuming the libquadmath-support was the same (as it was in my case). Not much can be done if the packages get it wrong. Thanks for the help. I'll close the bug report.
[Bug bootstrap/48471] [4.7 Regression] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 Nathan Froyd changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Nathan Froyd 2011-04-06 01:07:14 UTC --- Fixed on trunk.
[Bug bootstrap/48471] [4.7 Regression] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 --- Comment #6 from Nathan Froyd 2011-04-06 01:06:44 UTC --- Author: froydnj Date: Wed Apr 6 01:06:42 2011 New Revision: 172016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172016 Log: PR bootstrap/48471 * dbxout.c (debug_nesting, symbol_queue, symbol_queue_index): Move these... (symbol_queue_size, DBXOUT_DECR_NESTING): ...and these... (DBXOUT_DECR_NESTING_AND_RETURN): ...and this under #ifdef DBX_DEBUGGING_INFO. Modified: trunk/gcc/ChangeLog trunk/gcc/dbxout.c
[Bug other/48445] Release does not generate fixincludes directory needed by Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48445 --- Comment #9 from Blanca Mancilla 2011-04-06 00:50:09 UTC --- Yeap! The problem was the libraries not found and the make install assumming make run without error. I had a conflict between the ubuntu c++ and 4.7 in some other program and while testing, commented the library path line in my bashrc. Also, should change the script to make && make install, instead of having them in as separate commands to avoid the misleading messages. Thanks for the comments.
[Bug rtl-optimization/48473] [4.7 Regression] libstdc++-v3/testsuite/decimal/incdec.cc FAILs with -O -fno-tree-dce -fno-tree-fre -fno-tree-sra -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48473 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug rtl-optimization/48434] [4.7 Regression] Large SpecCPUFP Performance Regression for Thumb-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48434 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.7.0 Summary|Large SpecCPUFP Performance |[4.7 Regression] Large |Regression for Thumb-2 |SpecCPUFP Performance ||Regression for Thumb-2
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.7.0 Summary|Regression @171649: ICE in |[4.7 Regression] @171649: |setup_pressure_classes, at |ICE in |ira.c:877 |setup_pressure_classes, at ||ira.c:877
[Bug lto/47889] [4.6/4.7 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug lto/47888] [4.6/4.7 Regression] tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6249 / Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47888 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.5.3
[Bug c++/42687] [4.4/4.5/4.6/4.7 Regression] The prevention of ADL with the help of parentheses doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42687 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.4.6
[Bug tree-optimization/48330] [4.7 Regression] ICE: in optimize_inline_calls, at tree-inline.c:4201 with -fmudflap -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48330 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug inline-asm/48435] [4.7 Regression] Assertion failure during IRA (df_scan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48435 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code, ra Target Milestone|--- |4.7.0 Summary|Assertion failure during|[4.7 Regression] Assertion |IRA (df_scan) |failure during IRA ||(df_scan)
[Bug debug/48459] [4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|other |debug Target Milestone|--- |4.7.0 Summary|avr: Assertion failure with |[4.7 Regression] avr: |-gdwarf-2 |Assertion failure with ||-gdwarf-2
[Bug other/48445] Release does not generate fixincludes directory needed by Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48445 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.04.06 00:18:22 Ever Confirmed|0 |1
[Bug bootstrap/48471] [4.7 Regression] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |4.7.0 Summary|ia64-*-* does not bootstrap |[4.7 Regression] ia64-*-* |due to unused variables in |does not bootstrap due to |dbxout.c|unused variables in ||dbxout.c
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug tree-optimization/48475] New: gcc.dg/initpri3.c FAILs with -flto -O2 --param partial-inlining-entry-probability=100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48475 Summary: gcc.dg/initpri3.c FAILs with -flto -O2 --param partial-inlining-entry-probability=100 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23892 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23892 preprocessed source Output: $ gcc -flto -O2 --param partial-inlining-entry-probability=100 initpri3.i $ ./a.out Aborted (gdb) bt #0 0x77a98c05 in raise () from /lib/libc.so.6 #1 0x77a9a5b6 in abort () from /lib/libc.so.6 #2 0x00400657 in main () at /mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/initpri3.c:62 Tested revisions: r171998 - fail 4.6 r171597 - fail 4.5 - doesn't know --param partial-inlining-entry-probability
[Bug debug/47919] -fcompare-debug failure with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47919 --- Comment #3 from Alexandre Oliva 2011-04-05 23:37:52 UTC --- Nevermind, I switched back to the old tree and found out the second testcase is a different problem (or at least one that is not fixed by the patch for bug 47994)
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Paolo Carlini changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #3 from Paolo Carlini 2011-04-05 23:27:06 UTC --- Right now I'm traveling and I have trouble working on this issue. Anyway, if the only problem is the undefined symbol, we could as well export it and be done. Looks like we are also in the pretty lucky situation that 4.6.0 just came out and 4.5 was ok, thus we can have the fix in 4.6.1 and mainline without special problems with the exports, we have just to add the export at a new minor version. To be safe, I'm adding Honza in CC (would not be the first time a spurious undefined symbol turned out not to be a library issue ;) and I'm not sure to understand the --param at issue well enough to exclude that possibility) In any case, let's make sure we resolve this in time for 4.6.1.
[Bug debug/47919] -fcompare-debug failure with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47919 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.05 23:14:49 AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Alexandre Oliva 2011-04-05 23:14:49 UTC --- The patch for bug 47994 fixes the first testcase. I couldn't duplicate the second failure with current trunk, even before the patch. Can you please confirm that the patch also fixes it, if you by any chance still have the old build around? If so, will you please mark this bug as a dupe? TIA,
[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 --- Comment #5 from Steve Ellcey 2011-04-05 23:12:25 UTC --- Bootstrap finished, everything looked good.
[Bug debug/47994] -fcompare-debug failure with -O2 -fpeel-loops -fno-rerun-cse-after-loop -fno-tree-loop-optimize -fno-web
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47994 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.05 23:00:46 AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Alexandre Oliva 2011-04-05 23:00:46 UTC --- Created attachment 23891 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23891 Patch that fixes the bug, testing Here's the patch I'm testing.
[Bug bootstrap/48474] gcc fails to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 --- Comment #1 from froydnj at codesourcery dot com 2011-04-05 22:50:53 UTC --- On Tue, Apr 05, 2011 at 10:42:03PM +, mrs at gcc dot gnu.org wrote: > I have a target port, but with the update to 4.6.0 from 4.5.1, it now fails to > build because it is trying to use dwarf instead of sjlj based exception > handling. Does defining TARGET_EXCEPT_UNWIND_INFO to sjlj_except_unwind_info fix things?
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #46 from Eric Botcazou 2011-04-05 22:46:08 UTC --- Presumably everywhere now.
[Bug bootstrap/48474] New: gcc fails to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474 Summary: gcc fails to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org I have a target port, but with the update to 4.6.0 from 4.5.1, it now fails to build because it is trying to use dwarf instead of sjlj based exception handling. I don't have an eh_return, and without this, the code in default_except_unwind_info will try and use UI_DWARF2 which can't possibly work. If I add code to turn off UI_DWARF2 when there is no eh_return pattern, everything builds again. diff --git a/gcc/targhooks.c b/gcc/targhooks.c index 225831b..e8afa81 100644 --- a/gcc/targhooks.c +++ b/gcc/targhooks.c @@ -1365,6 +1365,14 @@ default_except_unwind_info (struct gcc_options *opts ATTRIBUTE_UNUSED) return UI_SJLJ; #endif +#ifndef EH_RETURN_HANDLER_RTX +#ifndef HAVE_eh_return +#define HAVE_eh_return 0 +#endif + if (!HAVE_eh_return) +return UI_SJLJ; +#endif + /* ??? Change all users to the hook, then poison this. */ #ifdef DWARF2_UNWIND_INFO if (DWARF2_UNWIND_INFO)
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Bernd Schmidt changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |bernds at gcc dot gnu.org |gnu.org | --- Comment #7 from Bernd Schmidt 2011-04-05 22:41:07 UTC --- Created attachment 23890 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23890 Potential fix. Please test this patch.
[Bug c/48470] ICE in expand_expr_addr_expr_1 at expr.c:6835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48470 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2011-04-05 22:30:36 UTC --- I can easily reproduce the ICE with gcc-4.4.5 and 4.5.2 targeting arm-linux-gnueabi, using the command line gcc -O1 -S test.i -mcpu= etc options don't seem to make any difference. gcc-4.3.5 works. Haven't been able to check 4.6.0 yet because there the test case triggers errors in code that isn't valid C1X.
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #45 from Bernd Schmidt 2011-04-05 22:19:21 UTC --- Author: bernds Date: Tue Apr 5 22:19:17 2011 New Revision: 172006 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172006 Log: PR bootstrap/48403 * haifa-sched.c (schedule_block): Increment cycle_issued_insns only if old and new states differ. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c
[Bug c++/48472] some flavors of std::bind are included in the global namespace when you include with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48472 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2011-04-05 22:08:21 UTC --- right, this is Argument Dependent Lookup and is a feature of C++
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 --- Comment #2 from Zdenek Sojka 2011-04-05 21:47:55 UTC --- The problem might be the combination of the fact that _S_compare is static, and "extern template class basic_string < char >;" declaration.
[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Jeffrey A. Law 2011-04-05 21:43:23 UTC --- Fixed by recent checkin.
[Bug rtl-optimization/48473] New: [4.7 Regression] libstdc++-v3/testsuite/decimal/incdec.cc FAILs with -O -fno-tree-dce -fno-tree-fre -fno-tree-sra -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48473 Summary: [4.7 Regression] libstdc++-v3/testsuite/decimal/incdec.cc FAILs with -O -fno-tree-dce -fno-tree-fre -fno-tree-sra -m32 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: i686-pc-linux-gnu Created attachment 23889 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23889 reduced testcase Output: $ g++ -m32 -O -fno-tree-dce -fno-tree-fre -fno-tree-sra testcase.C $ ./a.out Aborted Diff between 4.6 and 4.7 output shows this: L8: movDWORD PTR [esp+4], 847249419#, +movDWORD PTR [esp], 847249419#, call__bid_nesd2# There seems to be one store to [esp] missing in 4.7 (marked by "+"). Tested revisions: r171998 - fail 4.6 r171597 - OK
[Bug libstdc++/48472] some flavors of std::bind are included in the global namespace when you include with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48472
--- Comment #1 from Andrew Pinski 2011-04-05
21:22:03 UTC ---
No this is not in the global namespace but rather namelookup looks at std::bind
when one of the arguments are in std namespace.
namespace std
{
class A
{};
}
namespace std
{
template
void g(void (*a)(A), A);
}
void h(std::A a)
{
g(&h, a);
}
[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 --- Comment #4 from Steve Ellcey 2011-04-05 21:20:09 UTC --- The patch looks good. I haven't finished my bootstrap but I am in stage2 and dbxout.c compiled correctly.
[Bug libstdc++/48472] New: some flavors of std::bind are included in the global namespace when you include with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48472
Summary: some flavors of std::bind are included in the global
namespace when you include with
-std=c++0x
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bla...@suitabletech.com
The following program compiles correctly. I believe it should not because bind
should not be in the global namespace. (If you take A out of std this program
fails as one would expect.)
-
// Compile with: g++ test.cpp -std=c++0x -c
#include
namespace std
{
class A
{};
}
void f(std::A a)
{
bind(&f, a);
}
-
Output of g++ -v:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 Nathan Froyd changed: What|Removed |Added CC||froydnj at gcc dot gnu.org --- Comment #3 from Nathan Froyd 2011-04-05 20:45:38 UTC --- Does the attached patch solve things?
[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 --- Comment #2 from Nathan Froyd 2011-04-05 20:45:20 UTC --- Created attachment 23888 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23888 untested patch
[Bug bootstrap/48469] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48469 --- Comment #5 from Steve Ellcey 2011-04-05 20:43:47 UTC --- I have submitted it as PR 48471.
[Bug bootstrap/48471] ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 --- Comment #1 from Steve Ellcey 2011-04-05 20:44:32 UTC --- FYI: I could not find a changelog entry for the r171981 change to dbxout.c.
[Bug bootstrap/48471] New: ia64-*-* does not bootstrap due to unused variables in dbxout.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48471 Summary: ia64-*-* does not bootstrap due to unused variables in dbxout.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@cup.hp.com I get these errors when bootstrapping on ia64-hp-hpux11.23. /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error: 'debug_nesting' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error: 'symbol_queue' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error: 'symbol_queue_index' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error: 'symbol_queue_size' defined but not used [-Werror=unused-variable] cc1: all warnings being treated as errors I believe they were caused by this checkin: r171981 | froydnj | 2011-04-05 05:02:55 -0700 (Tue, 05 Apr 2011) | 8 lines * debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete. (debug_free_queue, debug_nesting, symbol_queue_index): Delete. * final.c (debug_flush_symbol_queue, debug_queue_symbol): Move these... (debug_free_queue, debug_nesting, symbol_queue_index): ...and these... * dbxout.c: ...to here. Make static.
[Bug middle-end/48377] [4.6 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #7 from Matt Hargett 2011-04-05 20:39:33 UTC --- Created attachment 23887 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23887 reduced test case, commandline to compile in bug comments
[Bug middle-end/48377] [4.6 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #6 from Matt Hargett 2011-04-05 20:38:41 UTC --- in the 46bug/ dir in the attached tarball: g++ -O3 -g -I. -c te_field_id.cpp && g++ *.o -o test induces the crash: ==31412== General Protection Fault ==31412==at 0x400F38: TE_Field_id::Initialize_token_maps() (hashmap.hpp:710) ==31412==by 0x4017A8: main (te_main.cpp:5) This is the same crash I described before. Compiling with -O2 eliminates the crash. In te_field_id.hpp, there is a commented out __attribute__((optimize(2))). In the non-reduced case, adding that annotation just moves the crash around. I may file a separate bug for that, depending on the outcome of this bug.
[Bug bootstrap/48469] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48469 Nathan Froyd changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||froydnj at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Nathan Froyd 2011-04-05 20:36:15 UTC --- No, it's not the same change. If you like, you could open a different PR and I could attach a patch I think works.
[Bug bootstrap/48469] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48469 Steve Ellcey changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #3 from Steve Ellcey 2011-04-05 20:32:01 UTC --- Is this the same problem I am seeing on IA64: /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error: 'debug_nesting' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error: 'symbol_queue' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error: 'symbol_queue_index' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error: 'symbol_queue_size' defined but not used [-Werror=unused-variable] cc1: all warnings being treated as errors I think it is coming from this change, though I don't see a ChangeLog entry for it. r171981 | froydnj | 2011-04-05 05:02:55 -0700 (Tue, 05 Apr 2011) | 8 lines * debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete. (debug_free_queue, debug_nesting, symbol_queue_index): Delete. * final.c (debug_flush_symbol_queue, debug_queue_symbol): Move these... (debug_free_queue, debug_nesting, symbol_queue_index): ...and these... * dbxout.c: ...to here. Make static.
[Bug c/48470] New: ICE in expand_expr_addr_expr_1 at expr.c:6835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48470 Summary: ICE in expand_expr_addr_expr_1 at expr.c:6835 Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: gcc.ourteddyb...@xoxy.net Created attachment 23886 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23886 Proprocessed source (built with -E, since -save-temps is an unrecognized option) Version (output from --version, since -v is apparently a verbose flag, not a version flag): GNU C (GCC) version 4.4.5 (arm-unknown-elf) compiled by GNU C version 3.4.4 (mingw special), GMP version 4.3.2, MPFR version 2.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Command line: "C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 2.0/gcc/bin/cc1" -fmessage-length=0 -mcpu=arm7tdmi -mthumb-interwork -mlittle-endian -mfpu=vfp -mfloat-abi=soft -nostdinc "-isystemC:/Program Files/Rowley Associates Limited/CrossWorks for ARM 2.0/include" "-isystemC:/Documents and Settings/sacleary/Local Settings/Application Data/Rowley Associates Limited/CrossWorks for ARM/packages/include" "-IC:/Code/v2/LN-200 IMU/../Components/include/FreeRTOS" "-IC:/Code/v2/LN-200 IMU/../Components/include/lwIP" "-IC:/Code/v2/LN-200 IMU/../Components/include/lwIP/ipv4" "-IC:/Code/v2/LN-200 IMU/../Components/include/lwIP glue" -I. "-IC:/Code/v2/LN-200 IMU/../Components/include" "-IC:/Code/v2/LN-200 IMU/../Common" -D__ARM_ARCH_4T__ -D__CROSSWORKS_ARM -D__CROSSWORKS_MAJOR_VERSION=2 -D__CROSSWORKS_MINOR_VERSION=0 -D__CROSSWORKS_REVISION=8 -D__TARGET_PROCESSOR=AT91SAM7X256 -DOSCILLATOR_CLOCK_FREQUENCY=18432000 "-DBOARDINIPATH = "imu.ini"" "-DdefaultIPAddr = 0x0006000A" "-DdefaultCANAddr = 0x00100600" "-DdefaultMacAddrA = 0x06" "-DBOARD_ID = BOARD_TYPE_LN200" "-D_DRIVES = 1" -D__THUMB -D__FLASH_BUILD -DNDEBUG -DSAM7_GCC -DTHUMB_INTERWORK -DSUPERVISOR_START -DSMARTPIGHARDWARE -MD "FPGA ISR.d" -MQ "FPGA ISR.o" -Werror -quiet -g1 -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fms-extensions -O1 -fno-dwarf2-cfi-asm -fno-builtin "C:/Code/v2/LN-200 IMU/FPGA ISR.c"
[Bug bootstrap/48469] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48469 --- Comment #2 from Nathan Froyd 2011-04-05 19:33:52 UTC --- Author: froydnj Date: Tue Apr 5 19:33:49 2011 New Revision: 171998 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171998 Log: PR bootstrap/48469 * combine.c (combine_instructions): #ifdef AUTO_INC_DEC links declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug bootstrap/48469] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48469 H.J. Lu changed: What|Removed |Added CC||froydnj at codesourcery dot ||com Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu 2011-04-05 19:30:49 UTC --- It may be caused by revision 171995: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00188.html
[Bug bootstrap/48469] New: [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48469 Summary: [4.7 Regression] bootstrap failure Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 171995 gave ../../src-trunk/gcc/combine.c: In function 'combine_instructions': ../../src-trunk/gcc/combine.c:1142:17: error: unused variable 'links' [-Werror=unused-variable]
[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466 --- Comment #2 from H.J. Lu 2011-04-05 19:12:53 UTC --- (In reply to comment #1) > Created attachment 23885 [details] > gcc46-pr48466.patch > > This seems to work and doesn't regress PR36977 (which I've added as guality > testcase too). Whether it is the right thing to do, I'm not 100% sure though. > H.J.? Looks good to me. Thanks.
[Bug gcov-profile/48463] gcov generating bad function coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48463 Andrew Pinski changed: What|Removed |Added Severity|major |normal --- Comment #1 from Andrew Pinski 2011-04-05 19:02:57 UTC --- >The mangled names differ only in the parts: D0, D1, D2. This is because the ABI defines these names. IIRC this has been improved in 4.5 or 4.6 where only one gets defined now and the rest are aliases.
[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466 --- Comment #1 from Jakub Jelinek 2011-04-05 18:55:37 UTC --- Created attachment 23885 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23885 gcc46-pr48466.patch This seems to work and doesn't regress PR36977 (which I've added as guality testcase too). Whether it is the right thing to do, I'm not 100% sure though. H.J.?
[Bug fortran/48404] SELECTED_REAL_KIND is returning KIND=16 when not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48404 --- Comment #7 from Scot Breitenfeld 2011-04-05 18:46:26 UTC --- (In reply to comment #3) > Thus: How have you obtained the compiler? Are you sure that the correct > compiler/library combination is used? > One compiler was from Debian packages, other compilers were from compiling from source. Rolling back libgfortran to find an older version fixes the problem. I guess the best solution is to compile the code with -static to avoid the issue. Probably can close the bug report.
[Bug c++/48468] New: [C++0x][SFINAE] noexcept operator does handle function templates well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48468
Summary: [C++0x][SFINAE] noexcept operator does handle function
templates well
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
template
T&& declval() noexcept;
template< class T >
inline void f1( T& x ) noexcept( noexcept( declval().foo() ) )
{
x.foo();
}
template< class T,
bool Noexcept = noexcept( declval().foo() )
>
inline void f2( T& x ) noexcept( Noexcept )
{
x.foo();
}
// a common and trivial mistake
template< class T >
inline void f3( T& x ) noexcept( declval().foo() )
{
x.foo();
}
struct X
{
void foo();
};
struct Y
{
void foo() noexcept;
};
struct Z {};
int main()
{
X x; Y y; Z z;
static_assert( !noexcept( f1(x) ), "OK." );
static_assert( !noexcept( f2(x) ), "OK." );
// static_assert( !noexcept( f3(x) ), "shall be ill-formed(OK)." );
static_assert( noexcept( f1(y) ), "OK." );
static_assert( noexcept( f2(y) ), "OK." );
// static_assert( noexcept( f3(y) ), "shall be ill-formed(OK)." );
static_assert( noexcept( f1(z) ), "shall be ill-formed." );
static_assert( noexcept( f2(z) ), "shall be ill-formed." );
static_assert( !noexcept( f3(z) ), "shall be ill-formed." );
}
-
GCC-4.6.0 compiles this code successfully, but expressions "noexcept( f1(z) )",
"noexcept( f2(z) )", and "noexcept( f3(z) )" shall be ill-formed, because
unevaluated operand "declval().foo()" is ill-formed.
This behavior prevents using noexcept for switching implementations by SFINAE:
-
// if x.swap(y) is exist, calls it.
template
void my_swap_( T& x, T& y, int )
noexcept( noexcept( std::declval().swap( std::declval() ) ) )
{
x.swap( y );
}
// otherwise, calls [std::]swap
using std::swap;
template
void my_swap_( T& x, T& y, ... )
noexcept( noexcept( swap( std::declval(), std::declval() ) ) )
{
swap( x, y );
}
template
void my_swap( T& x, T& y )
noexcept( noexcept( my_swap_( std::declval(), std::declval(), 0 ) ) )
{
my_swap_( x, y, 0 );
}
-
Of course, this code can be written with another C++0x feature (e.g. decltype),
I'd prefer to use noexcept when result type is void, because it's simple.
[Bug lto/48467] New: [LTO/driver] Anomalous behavior of -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48467 Summary: [LTO/driver] Anomalous behavior of -save-temps Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23884 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23884 DIFF file with 4 tests 1. After running the 1st test, notice the absence of one generated assembler file (1.s), which is deleted by lto1. In toplev.c, 1851 if (flag_wpa) 1852unlink_if_ordinary (asm_file_name); 2. As the 2nd and 3rd tests show, it can also be misused as an output file for lto1, so its original, written by cc1, content gets lost. 3. The 4th test gives good, expected results.
[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48441 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Steven Bosscher 2011-04-05 18:16:34 UTC --- Eet eez feexeth.
[Bug middle-end/48441] [4.7 Regression] ICE in mark_oprs_set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48441 --- Comment #8 from Steven Bosscher 2011-04-05 18:15:08 UTC --- Author: steven Date: Tue Apr 5 18:15:04 2011 New Revision: 171994 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171994 Log: PR middle-end/48441 * cprop.c (one_cprop_pass): Do not mark_oprs_set of deleted insns. Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c
[Bug debug/48466] [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.4.6
[Bug debug/48466] New: [4.4/4.5/4.6 Regression] Wrong variable locations at -O0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48466
Summary: [4.4/4.5/4.6 Regression] Wrong variable locations at
-O0 on i686
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: tro...@gcc.gnu.org, h...@gcc.gnu.org
struct S { int a; int *b; };
struct T { struct S a; struct S b; };
struct U { const char *u; };
int n[10];
volatile int v;
struct U
foo (const char *s)
{
struct U r;
r.u = s;
return r;
}
void
bar (struct T *s, int a, int b)
{
s->a.a = a;
s->a.b = &s->a.a;
s->b.a = b;
s->b.b = &s->b.a;
}
int
main ()
{
struct T t;
struct U x = foo ("this is x");
struct S y, z;
y.b = n;
y.a = 0;
bar (&t, 1, 2);
v++;
z = y;
return 0;
}
compiled with -g -O0 -dA, when you debug this in the debugger, &t is different
from the address passed to bar and after the bar call t contains garbage.
Most likely this started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138438
The t variable has DECL_RTL (mem (plus (frame) (const_int -16)), (frame) is
eliminated to bp - 4, but crtl->stack_realign_tried is true (eventhough
fde->stack_realign is false) and thus it is encoded as sp - 20 instead of bp -
20. fde->drap_reg is -1.
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02391.html
[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #2 from Steven Bosscher 2011-04-05 18:00:12 UTC --- Do you have compiler options for a particularly bad configuration? Which benchmark files grow the most?
[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.05 17:23:03 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-04-05 17:23:03 UTC --- I can reproduce this, but I don't think it can be a libstdc++ bug when it depends on optimisation and --param=hot-bb-frequency-fraction=1
[Bug libstdc++/48465] New: [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48465 Summary: [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23883 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23883 reduced testcase Compiler output: $ g++ -finline-small-functions -O testcase.C --param=hot-bb-frequency-fraction=1 /tmp/ccRTQGpy.o: In function `foo(int, int, char*)': testcase.C:(.text+0x70): undefined reference to `std::basic_string, std::allocator >::_S_compare(unsigned long, unsigned long)' collect2: ld returned 1 exit status Tested revisions: r171979 - fail 4.6 r171597 - fail 4.5 r171597 - OK
[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #8 from Steven Bosscher 2011-04-05 16:47:41 UTC --- (In reply to comment #6) > FWIW, --enable-checking=release and --disable-checking are the same code path Is this really true? I thought that assert checking is also disabled with --disable-checking, but that it's enabled with release checking...?
[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46040 Ramana Radhakrishnan changed: What|Removed |Added CC||carrot at google dot com --- Comment #12 from Ramana Radhakrishnan 2011-04-05 16:36:31 UTC --- *** Bug 46548 has been marked as a duplicate of this bug. ***
[Bug target/46548] Build arm gcc failure after patch 165463
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46548 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #6 from Ramana Radhakrishnan 2011-04-05 16:36:31 UTC --- It probably is a dup of PR46040 I think . Ah I remember now. Ramana *** This bug has been marked as a duplicate of bug 46040 ***
[Bug target/46548] Build arm gcc failure after patch 165463
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46548 --- Comment #5 from Nathan Froyd 2011-04-05 16:33:00 UTC --- I believe this was fixed by the fix for PR 46040.
[Bug target/48328] GCC failed to generate 16bit relative jump table
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48328 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |4.7.0 Severity|normal |enhancement
[Bug target/46548] Build arm gcc failure after patch 165463
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46548 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan 2011-04-05 16:30:33 UTC --- Is this now fixed ?
[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan 2011-04-05 16:22:30 UTC --- Can you show the assembler generated here ? I don't see the same error that you get here with a cross-compiler. Ramana
[Bug middle-end/48464] Regression @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 Jan-Benedict Glaw changed: What|Removed |Added Target||vax-linux CC||jbg...@lug-owl.de, vmakarov ||at redhat dot com Host||i686-linux Build||i686-linux --- Comment #1 from Jan-Benedict Glaw 2011-04-05 16:07:47 UTC --- Hint for VCS users (as bugzilla only wants to see released version names). Known to work: r171648 = 9f50fa3742ab7c20e3e8ceb48b26c920b22ecd62 Known to fail: r171649 = 66d9a7b9e8a0c85a51467330f51ead74e7
[Bug middle-end/48464] New: Regression @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464
Summary: Regression @171649: ICE in setup_pressure_classes, at
ira.c:877
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jbg...@lug-owl.de
Hi!
The large IRA merge (=66d9a7b9e8a0c85a51467330f51ead74e77b7eb8 in GIT) broke
the vax-linux target:
jbglaw@jbarbeitsplatz:/mnt/nfs-programming/toolchain/gcc-build/gcc$ ./xgcc -B .
-c foo.c
foo.c:1:0: internal compiler error: in setup_pressure_classes, at ira.c:877
Please submit a full bug report,
[...]
jbglaw@jbarbeitsplatz:/mnt/nfs-programming/toolchain/gcc-build/gcc$ cat foo.c
extern int xx (int a, int b);
int
blub (double boo, int oo)
{
long x;
x = boo * oo;
x += xx (boo, oo);
return x;
}
This is just configured with ../gcc/configure --target=vax-linux
--enable-languages=c --disable-threads on a i686-linux host/build system.
[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444 --- Comment #7 from Jeffrey A. Law 2011-04-05 16:03:32 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 09:58, bkoz at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444 > > Benjamin Kosnik changed: > >What|Removed |Added > >Target Milestone|4.7.0 |--- > > --- Comment #6 from Benjamin Kosnik 2011-04-05 > 15:58:33 UTC --- > > Hey Jeff. Yes, I always build with checking disabled, as it means libstdc++ > make check is 27 minutes, not 40. I should have given you a configure line on > #gcc. > > FWIW, --enable-checking=release and --disable-checking are the same code path No worries. I've got my bit of mess from this shit-storm under control. It'll take a few hours to get all the tests run, but I'm confident my little piece will get fixed shortly :-) jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmz1EAAoJEBRtltQi2kC7TDsH/AiduwnUnU9BxzhdBXN2+z3h BpEEthsww2Ns731aRb7XECf0MyzocOjKG6X4KUI/VWpG3Xoi4f+RoRstjsl5UbQi zeEv88gq4Dw/QbZs/LHFYfa9mpaY2bsrT7yK9EUEYVCc5nfjcoVAh95rGPMv9vVz HQFCHc/AQdxpMIGiX1/Y4CPBPj1vIEcJ49yv9dSy5AdkDSLEhD77KCfh1AvtFG1j q9VfO12Wpg3yYt4ojg7WLXVSb1g/8/6WnSzn6IjpEpIRdAxL47BRTp66wAfVXxu9 x0fPCkORh+E1lJGyfSatEtC6iOTiYDu8HIehKF9wJQ/DJ5WNYHLZEr2uewo/LFA= =vSy+ -END PGP SIGNATURE-
[Bug middle-end/48461] [4.7 Regression] function.c:5268:1: error: emit_use_return_register_into_block defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48461 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from vries at gcc dot gnu.org 2011-04-05 16:01:17 UTC --- The function emit_use_return_register_into_block is only used in code guarded with HAVE_return, and therefore the definition of emit_use_return_register_into_block should also be guarded with HAVE_return. Failing to do this caused the error mentioned in the description field. This is fixed by the check-in in comment 1.
[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444 Benjamin Kosnik changed: What|Removed |Added Target Milestone|4.7.0 |--- --- Comment #6 from Benjamin Kosnik 2011-04-05 15:58:33 UTC --- Hey Jeff. Yes, I always build with checking disabled, as it means libstdc++ make check is 27 minutes, not 40. I should have given you a configure line on #gcc. FWIW, --enable-checking=release and --disable-checking are the same code path
[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org Depends on||48360 Target Milestone|--- |4.6.1 Summary|[4.6/4.7 Regression] matmul |[4.6/4.7 Regression] |Segmentation Fault with |realloc on assignment: |Allocatable Array |matmul Segmentation Fault ||with Allocatable Array --- Comment #3 from Tobias Burnus 2011-04-05 15:57:52 UTC --- Work around: -fno-realloc-lhs See also other (re)allocation on assignment related bugs: PR 48360 and 48456.
[Bug middle-end/48461] [4.7 Regression] function.c:5268:1: error: emit_use_return_register_into_block defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48461 --- Comment #1 from vries at gcc dot gnu.org 2011-04-05 15:54:17 UTC --- Author: vries Date: Tue Apr 5 15:54:13 2011 New Revision: 171990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171990 Log: 2011-04-05 Tom de Vries PR middle-end/48461 * function.c (emit_use_return_register_into_block): Only define if HAVE_return. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #44 from Jeffrey A. Law 2011-04-05 15:45:20 UTC --- Just a note for those experiencing a comparison failure with --disable-checking, I know what's causing it and should have a fix shortly. That failure is being tracked by PR48444.
[Bug other/46489] tree optimizer and frontend files use target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #7 from Joseph S. Myers 2011-04-05 15:43:46 UTC --- FWIW, the following files include tm.h and appear not to have any direct uses of target macros, or uses of the most common headers (such as rtl.h or cp-tree.h) that depend on tm.h. They require more careful checks of what headers they are using for any hidden tm.h dependencies, but may be good candidates for the removal of tm.h includes. gcc/ada/gcc-interface/cuintp.c gcc/attribs.c gcc/c-aux-info.c gcc/c-convert.c gcc/c-errors.c gcc/c-family/c-ada-spec.c gcc/c-family/c-dump.c gcc/c-family/c-gimplify.c gcc/c-family/c-pretty-print.c gcc/c-family/c-semantics.c gcc/c-lang.c gcc/c-parser.c gcc/cgraphbuild.c gcc/cppspec.c gcc/debug.c gcc/domwalk.c gcc/fixed-value.c gcc/gencheck.c gcc/gimple-iterator.c gcc/gimple-low.c gcc/gimple-pretty-print.c gcc/hooks.c gcc/ipa-pure-const.c gcc/ipa-reference.c gcc/ipa-utils.c gcc/java/except.c gcc/java/jvgenmain.c gcc/java/jvspec.c gcc/java/mangle.c gcc/java/zextract.c gcc/lto-section-in.c gcc/lto-section-out.c gcc/lto-streamer-out.c gcc/lto-streamer.c gcc/lto/lto.c gcc/main.c gcc/objc/objc-lang.c gcc/params.c gcc/print-tree.c gcc/tree-call-cdce.c gcc/tree-cfg.c gcc/tree-cfgcleanup.c gcc/tree-complex.c gcc/tree-dump.c gcc/tree-eh.c gcc/tree-if-conv.c gcc/tree-into-ssa.c gcc/tree-nomudflap.c gcc/tree-nrv.c gcc/tree-optimize.c gcc/tree-outof-ssa.c gcc/tree-predcom.c gcc/tree-pretty-print.c gcc/tree-profile.c gcc/tree-ssa-coalesce.c gcc/tree-ssa-copy.c gcc/tree-ssa-copyrename.c gcc/tree-ssa-dce.c gcc/tree-ssa-dom.c gcc/tree-ssa-dse.c gcc/tree-ssa-ifcombine.c gcc/tree-ssa-live.c gcc/tree-ssa-loop-ch.c gcc/tree-ssa-loop-im.c gcc/tree-ssa-loop-ivcanon.c gcc/tree-ssa-loop-manip.c gcc/tree-ssa-loop-niter.c gcc/tree-ssa-loop-unswitch.c gcc/tree-ssa-loop.c gcc/tree-ssa-operands.c gcc/tree-ssa-phiopt.c gcc/tree-ssa-phiprop.c gcc/tree-ssa-pre.c gcc/tree-ssa-propagate.c gcc/tree-ssa-reassoc.c gcc/tree-ssa-sink.c gcc/tree-ssa-ter.c gcc/tree-ssa-threadedge.c gcc/tree-ssa-threadupdate.c gcc/tree-ssa-uncprop.c gcc/tree-ssa-uninit.c gcc/tree-ssanames.c gcc/tree-stdarg.c gcc/tree-switch-conversion.c gcc/tree-tailcall.c gcc/tree-vect-patterns.c gcc/tree-vect-slp.c gcc/tree-vectorizer.c gcc/tree-vrp.c libdecnumber/dconfig.h libgcc/generic-morestack-thread.c
[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.05 15:43:17 Ever Confirmed|0 |1
[Bug bootstrap/48444] [4.7 Regression] bootstrap failure with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48444 Jeffrey A. Law changed: What|Removed |Added AssignedTo|unassigned at gcc dot |law at redhat dot com |gnu.org | --- Comment #5 from Jeffrey A. Law 2011-04-05 15:42:31 UTC --- I've got a handle on this one...
[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 --- Comment #2 from Joost VandeVondele 2011-04-05 15:40:41 UTC --- somewhat reduced: program main implicit none integer, parameter :: dp = kind(0.0d0) real(kind=dp), allocatable :: a(:,:) real(kind=dp), allocatable :: b(:,:) allocate(a(3,3)) allocate(b(3,3)) a = matmul( matmul( a, b ), b ) ! Segmentation Fault end program main
[Bug fortran/48462] [4.6/4.7 Regression] matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Joost VandeVondele changed: What|Removed |Added Keywords||wrong-code Known to work||4.5.0 Summary|matmul Segmentation Fault |[4.6/4.7 Regression] matmul |with Allocatable Array |Segmentation Fault with ||Allocatable Array Known to fail||4.6.1, 4.7.0 --- Comment #1 from Joost VandeVondele 2011-04-05 15:38:21 UTC --- so, the segfault is at run time. 4.5 is doing fine. ==14586== Invalid read of size 8 ==14586==at 0x4EC9AD1: _gfortran_matmul_r8 (matmul_r8.c:284) ==14586==by 0x400877: main (in /data03/vondele/bugs/a.out) ==14586== Address 0x0 is not stack'd, malloc'd or (recently) free'd looks like an important issue to me.
[Bug gcov-profile/48463] gcov generating bad function coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48463 Christian changed: What|Removed |Added Severity|normal |major
[Bug gcov-profile/48463] New: gcov generating bad function coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48463
Summary: gcov generating bad function coverage
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lieutenantfe...@hotmail.de
Created attachment 23882
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23882
1.png, 2.png, src/ (has 3 source files)
Gcov is generating a lot of useless output when it comes to function coverage.
The problem really came to our attention when looking at classes with virtual
destructors like the one in the following class example:
[code]
class ClassA
{
public:
ClassA();
virtual ~ClassA();
};
class ClassB : public ClassA
{
public:
ClassB();
~ClassB();
};
[/code]
The list of function names then contains three destructors for ClassA (two of
which are apparently not called, one which is) and three destructors for ClassB
(two of which are apparently not called, one which is). They all have the same
signature. When disabling then genhtml option --demangle-cpp, or by viewing the
.gcov files, you can see, that each of these destructors (of ClassA for
example) has a different name. Example (excerpt of gcov file for classA.cpp):
Function '_ZN6ClassAD0Ev'
Lines executed:0.00% of 3
Branches executed:0.00% of 2
Taken at least once:0.00% of 2
Calls executed:0.00% of 3
Function '_ZN6ClassAD1Ev'
No executable lines
Branches executed:0.00% of 2
Taken at least once:0.00% of 2
Calls executed:0.00% of 3
Function '_ZN6ClassAD2Ev'
No executable lines
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:66.67% of 3
The mangled names differ only in the parts: D0, D1, D2. It's odd that one
destructor apparently has 3 executable lines (in the attached source, you can
see it's only one line), and that the two others have no executable lines, yet
they have branches that can be covered.
These "IDs" 'D0', 'D1', 'D2' are given to the mangled function names by the gcc
compiler, yet I am unsure of what the difference is supposed to be.
Nevertheless, it isn't really of interest to the person analyzing the coverage
of his code, what gcc generates in the background. Only those desctructors,
that the programmer can actually see in HIS code, should show up in the list of
covered (or not covered) functions.
This goes for the other functions that show up in the example's list as well:
global destructors keyed to _ZN6ClassAC2Ev
global constructors keyed to _ZN6ClassAC2Ev
__static_initialization_and_destruction_0(int, int)
It leads to wrong numbers for the function and branch coverage of what you
really want to see.
To reproduce:
I wrote a two classes: ClassA and ClassB. ClassA has a public constructor (no
args, just prints something) and a public virtual destructor (no args, just
prints something). ClassB inherits from ClassA (publicly) and has a public
constructor (no args, just prints something) and a public destructor (no args,
just prints something). The main file just creates an instance of ClassB,
stores it in a pointer to ClassA and calls delete on that pointer variable.
The source files were compiled using:
g++ -fprofile-arcs -ftest-coverage -o prog main.cpp classA.cpp
Then ./prog was run once.
A .info file was generated using lcov (version 1.9) in the following command:
lcov -d . -c -f -o NewInfo.info
The final html overview was generated using genhtml (also version 1.9) in the
following command:
genhtml --demangle-cpp --prefix . -o html/ NewInfo.info
Alternatively, to reproduce, you can also use the attached source files. The
attachment also include two pictures, displaying a listing of all the functions
that have apparently been covered or not covered.
Hope this info helps solve the problem.
Chris
[Bug middle-end/48461] [4.7 Regression] function.c:5268:1: error: emit_use_return_register_into_block defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48461 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0 Summary|[4.7 Regression |[4.7 Regression] |function.c:5268:1: error: |function.c:5268:1: error: |emit_use_return_register_in |emit_use_return_register_in |to_block defined but not|to_block defined but not |used|used
[Bug middle-end/48461] [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48461 vries at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | Target Milestone|4.7.0 |---
[Bug middle-end/48461] [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48461 Richard Guenther changed: What|Removed |Added Keywords||build Target||hppa-linux-gnu Target Milestone|--- |4.7.0
[Bug fortran/48462] New: matmul Segmentation Fault with Allocatable Array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48462 Summary: matmul Segmentation Fault with Allocatable Array Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ort...@gmail.com The segmentation fault occurs in the current stable release version of gcc (4.6.0). The release version source code was downloaded from a gcc mirror and configured in the following way: Target: x86_64-apple-darwin10.6.0 Configured with: ../gcc-4.6.0/configure --prefix=$HOME/gcc/gcc-release --enable-languages=fortran --enable-checking=release --disable-bootstrap Thread model: posix gcc version 4.6.0 (GCC) Small example: ! matmulTester.f90 program main implicit none integer, parameter :: dp = kind(0.0d0) real(kind=dp), allocatable :: a(:,:) real(kind=dp), allocatable :: b(:,:) allocate(a(3,3)) allocate(b(3,3)) a(1,:) = [ 3.11_dp, 3.12_dp, 3.13_dp ] a(2,:) = [ 3.21_dp, 3.22_dp, 3.23_dp ] a(3,:) = [ 3.31_dp, 3.32_dp, 3.33_dp ] b = 6.0_dp * a a = matmul( matmul( a, b ), b ) ! Segmentation Fault end program main The segmentation fault occurs on the last line of the program above. It can be fixed by separating the lines: a = matmul(a,b) a = matmul(a,b) The segmentation fault also disappears, and the program runs fine, if non-allocatable arrays are used for a and b. In addition, replacing the last line of the program with the following removes the segmentation fault: b = matmul( matmul( a, b ), b ) ! NO Segmentation Fault Also, the segmentation fault disappears when another allocatable array is introduced to the code above: real(kind=dp), allocatable :: c(:,:) allocate(3,3) ... c = matmul( matmul( a, b ), b ) ! NO Segmentation Fault I used the following command: gfortran -o matmulTester matmulTester.f90 Finally, building in debug mode and running yields the following: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x00010008b3ab in __gfortran_matmul_r8 (retarray=, a=, b=, try_blas=, blas_limit=24, gemm=0x18) at ../../../gcc-4.6.0/libgfortran/generated/matmul_r8.c:284 284 dest_y[x] += abase_n[x] * bbase_yn; I hope this is not a duplicate and was a worthwhile reporting. If not, I apologize. Thanks, John N.
[Bug middle-end/48461] New: [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48461 Summary: [4.7 Regression function.c:5268:1: error: emit_use_return_register_into_block defined but not used Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: vr...@gcc.gnu.org /home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/gcc/function.c -o function.o ../../gcc/gcc/function.c:5268:1: error: âemit_use_return_register_into_blockâ defined but not used [-Werror=unused-function] cc1: all warnings being treated as errors
[Bug middle-end/46500] target.h includes tm.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46500 --- Comment #6 from Joseph S. Myers 2011-04-05 15:17:44 UTC --- The cumulative_args_t changes should be updated and resubmitted now we are in 4.7 stage 1.
