[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 06:35:21 UTC --- Author: burnus Date: Sat May 14 06:35:18 2011 New Revision: 173748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173748 Log: 2011-05-14 Tobias Burnus bur...@net-b.de PR fortran/48961 * intrinsics/execute_command_line.c (set_cmdstat): Don't abort if synchronously executing with WAIT=.false. (execute_command_line): Fix setting of cmdstat and exitstat. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/execute_command_line.c
[Bug libfortran/48915] Incorrect process return code with -fdump-core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48915 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-14 08:44:12 UTC --- Author: jb Date: Sat May 14 08:44:09 2011 New Revision: 173750 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173750 Log: PR 48915 Abort handling Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/abort.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/backtrace.c trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/environ.c trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/stop.c
[Bug libfortran/48915] Incorrect process return code with -fdump-core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48915 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-14 09:05:59 UTC --- Fixed, closing.
[Bug fortran/22572] Double occurrence of matmul intrinsic not optimised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22572 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-05-14 09:48:11 UTC --- Author: tkoenig Date: Sat May 14 09:48:08 2011 New Revision: 173752 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173752 Log: 2011-05-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/22572 * frontend-passes.c (cfe_register_funcs): Also register functions for potential elimination if the rank is 0, the shape is unknown and reallocate on assignment is active. (create_var): For rank 0 functions with unknown shape, create an allocatable temporary. 2011-05-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/22572 * function_optimize_7.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/function_optimize_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/22572] Double occurrence of matmul intrinsic not optimised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22572 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-05-14 09:50:46 UTC --- Fixed on trunk. Closing.
[Bug fortran/48997] New: Don't use allocatable arrays for function elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48997 Summary: Don't use allocatable arrays for function elimination Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Blocks: 36854 After revision 173752, double occurrence of functions returning arrays within an expression are removed using an allocatable array as temporary. It would be better to use BLOCK variables. Example: Transform function optmatmul (a, b, ni, nj) implicit none integer, intent(in) :: ni, nj double precision :: optmatmul(ni, nj) double precision, intent(in) :: a(ni, nj), b(ni, nj) optmatmul = matmul(a, b) / (1 + matmul(a, b)) end function optmatmul (the test case from PR 22572) to function optmatmul (a, b, c, m, n, count) implicit none integer, intent(in) :: m, n, count double precision :: optmatmul(m, n) double precision, intent(in) :: a(m, count), b(count, n), c(m, n) block double precision, dimension(size(a,1), size(b,2)) :: tmp tmp = matmul(a,b) optmatmul = tmp / (1 + tmp) end block end function optmatmul We would probably need argument mapping for this. Issues to be resolved: - This is complicated, especially for intrinsics which take their return size from their arguments - Especially ugly: pack - Also not nice: dim=n arguments where n is a variable - We would need a way to handle functions in argument lists specifying return dimensions, which we have to keep from being evaluated twice (not a likely corner case, but we have to be correct...)
[Bug libfortran/48915] Incorrect process return code with -fdump-core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48915 --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-14 10:20:59 UTC --- Author: jb Date: Sat May 14 10:20:56 2011 New Revision: 173753 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173753 Log: PR 48915 Update mixed-language programming documentation Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi
[Bug libfortran/48915] Incorrect process return code with -fdump-core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48915 --- Comment #6 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-14 10:24:20 UTC --- Author: jb Date: Sat May 14 10:24:18 2011 New Revision: 173754 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173754 Log: PR 48915 Update mixed-language programming documentation Modified: trunk/gcc/fortran/gfortran.texi
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #47 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 10:34:49 UTC --- Author: burnus Date: Sat May 14 10:34:44 2011 New Revision: 173755 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173755 Log: 2011-05-14 Tobias Burnus bur...@net-b.de PR fortran/18918 * interface.c (compare_parameter): Skip diagnostic if actual argument is not an array; rank mismatch is diagnosted later. 2011-05-14 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.de/coarray_20.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48998] New: ICE: verify_flow_info failed: Wrong frequency of block 227 -161996 with -O3 --param max-completely-peeled-insns=5000 --param max-predicted-iterations=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48998 Summary: ICE: verify_flow_info failed: Wrong frequency of block 227 -161996 with -O3 --param max-completely-peeled-insns=5000 --param max-predicted-iterations=1 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 24247 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24247 reduced testcase Compiler output: $ gcc -O3 --param max-completely-peeled-insns=5000 --param max-predicted-iterations=1 testcase.f90 -w testcase.f90: In function 'test': testcase.f90:1: error: verify_flow_info: Wrong frequency of block 227 -161996 testcase.f90:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The testcase was reduced from libgomp/testsuite/libgomp.fortran/vla[345].f90, which give: $ gcc -O3 --param max-completely-peeled-insns=5000 --param max-predicted-iterations=1 tmp.f90 tmp.f90: In function 'test': tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 2412 -421953 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 2410 -212029 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 2240 -421997 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 2238 -211986 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 2067 -422055 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 2066 -211338 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 1874 -422680 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 1871 -210004 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 1652 -211560 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 1437 -427383 tmp.f90:167:0: error: verify_flow_info: Wrong frequency of block 1435 -213946 tmp.f90:167:0: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. All
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 11:52:34 UTC --- EXECUTE_COMMAND_LINE(WAIT=.false.) now should no longer fail on systems without fork(). Remains to do: Implement asynchronous execution on MinGW, cf. attachment 24228.
[Bug fortran/48991] [4.7 Regression] FAIL: gfortran.dg/assign_8.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48991 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 11:52:49 UTC --- FIXED - thanks for the report
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 11:55:14 UTC --- Done: Constraint diagnostic of the Fortran standard. To be done: Adding vendor extension to support UCS-4 arguments to OPEN's and INQUIRE's file argument.
[Bug middle-end/48674] [4.7 Regression] FAIL: g++.dg/torture/pr48661.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48674 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-14 12:31:43 UTC --- These failures disappeared on between revisions 173492 and 173525 on powerpc-apple-darwin9.8 (see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00719.html and http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00759.html ) and revisions 173516 and 173518 on i686-pc-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00708.html and http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00718.html ). So this PR is fixed/hidden by revision 173517.
[Bug c++/48999] New: [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48999 Summary: [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin* Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ja...@redhat.com, froy...@codesourcery.com Between revisions 173448 and 173467 compiling g++.dg/torture/20090706-1.C gives and ICE on *-*-darwin* (see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00614.html and http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00654.html ). The ICE is /opt/gcc/work/gcc/testsuite/g++.dg/torture/20090706-1.C: In constructor 'CanonicalCenteringDim::CanonicalCentering() [with int Dim = 2]': /opt/gcc/work/gcc/testsuite/g++.dg/torture/20090706-1.C:41:37: internal compiler error: in bitmap_first_set_bit, at bitmap.c:782 Candidate revisions are 173449 (unlikely: the ICE occurs with both gcc and g++), 173451, 173465 (unlikely: objc stuff), and 173467.
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-14 12:54:26 UTC --- Maybe I'm wrong, but I'm not sure the current implementation of asynchronous execution is very efficient (on Unix systems): We fork() and then call system(), which forks again and runs a shell, then the shell exits, the forked process inside system() exits, the we exit our forked process. I think we might as well just fork and exec the shell directly which would save one process creation. We also don't need the exit value from the system() call in Fortran.
[Bug c++/48994] [4.7 regression] [C++0x] error for trivial use of range-based 'for'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48994
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.05.14 14:02:45
CC||jason at gcc dot gnu.org
Summary|[4.7 regression] error for |[4.7 regression] [C++0x]
|trivial use of range-based |error for trivial use of
|'for' |range-based 'for'
Ever Confirmed|0 |1
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-14
14:02:45 UTC ---
It only fails when the type is a reference to a template.
The relevant code is:
static tree
cp_parser_perform_range_for_lookup (tree range, tree *begin, tree *end)
{
if (!COMPLETE_TYPE_P (TREE_TYPE (range)))
{
error (range-based %for% expression of type %qT
has incomplete type, TREE_TYPE (range));
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 14:00:26 UTC --- (In reply to comment #8) We fork() and then call system(), which forks again and runs a shell, then the shell exits, the forked process inside system() exits, the we exit our forked process. I think we might as well just fork and exec the shell directly which would save one process creation. We also don't need the exit value from the system() call in Fortran. POSIX states for system: The environment of the executed command shall be as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows: execl(shell path, sh, -c, command, (char *)0); where shell path is an unspecified pathname for the sh utility. Thus, for a POSIX system, one could use: execlp (sh, sh, -c, command, (char*) 0); However, that assumes that there is a sh available. That's the advantage of system() that it is widely available and one avoids to specify the shell commands. One cannot do without the shell command as there are users, who want that using 'system(./foo bar.dat)' works. Thus, I do not see how one can solve this better than currently done.
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 14:05:19 UTC --- (In reply to comment #9) execl(shell path, sh, -c, command, (char *)0); where shell path is an unspecified pathname for the sh utility. Thus, for a POSIX system, one could use: execlp (sh, sh, -c, command, (char*) 0); Actually, via confstr(_CS_PATH, buf, sizeof(buf)) one can find the path. Nevertheless, calling sh assumes that one has a POSIX system; I am pretty sure that it would fail on MinGW - even though, system() works there. Maybe, one can use some configure check to know whether sh is available. However, the check should be cross-compile friendly.
[Bug libfortran/48931] Backtrace functionality not async-signal-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48931 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-14 15:15:56 UTC --- Assigning to myself.
[Bug lto/48384] lto, linker-plugin and optimization clutter the stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384 Lassi Tuura lat at cern dot ch changed: What|Removed |Added CC||lat at cern dot ch --- Comment #6 from Lassi Tuura lat at cern dot ch 2011-05-14 15:41:35 UTC --- I think this is an issue I previous looked at for Vincenzo, and concluded that LTO-generated binary has unwind info referring to the wrong ELF base section, .eh_frame, rather than .text, completely messing up any attempt to unwind. I don't have immediate access to the exact tool chain used for this bug report so can't replicate the necessary info right now, but I've attached a previous analysis I sent to Vincenzo. If this isn't sufficient to put investigation on the right track, I'll get together with Vincenzo next week and we will generate the necessary unwind info dumps for the specific test case he added here before. === At any rate the unwind info is completely messed up. For example from readelf -Wwf libfoo_hlto.so we have a claim there is a function at pc=07a0..086f. 0020 fea8 001c FDE cie=0008 pc=07a0..086f DW_CFA_advance_loc: 2 to 07a2 DW_CFA_def_cfa_offset: 16 DW_CFA_offset: r12 (r12) at cfa-16 DW_CFA_advance_loc: 4 to 07a6 DW_CFA_def_cfa_offset: 24 [...] But the only function of any significance in that library is not at that address, as shown by objdump -d libfoo_hlto.so. The FDE program looks correct otherwise, just is at wrong address. 0640 _Z2goiPKi: 640: 41 54 push %r12 642: 49 89 f4mov%rsi,%r12 645: 55 push %rbp 646: 8d 6c 3f 01 lea0x1(%rdi,%rdi,1),%ebp 64a: 53 push %rbx [...] 6ff: 5b pop%rbx 700: 5d pop%rbp 701: 41 5c pop%r12 703: c3 retq 704: e8 57 fe ff ff callq 560 sqrt@plt 709: c5 f9 28 c8 vmovapd %xmm0,%xmm1 70d: eb b9 jmp6c8 _Z2goiPKi+0x88 70f: 90 nop In fact there's nothing at all at the CIE range 07a0..086f - the address is in unwind info table itself (.eh_frame), not in the code. So it looks like whatever is generating this unwind info is generating wrong address references. $ readelf -WS libfoo_hlto.so There are 29 section headers, starting at offset 0x1100: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [...] [14] .eh_frame PROGBITS0778 000778 58 00 A 0 0 8 [15] .eh_frame_hdr PROGBITS07d0 0007d0 14 00 A 0 0 4 [...] Looks like your tool chain is broken. I don't know why.
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
--- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com
2011-05-14 16:18:58 UTC ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
This code is equivalent and is valid. At least, I don't see the Standard
forbidding it. GCC is the only compiler I tested (comeau/edg, clang) that
rejects it.
I'm not actually sure anymore about the validity of this code. One can make a
point about the initializer not being a mere string literal.
At least the draft n3126 makes a difference of this, in that an initializer
like ({a, b, c}) is not regarded as a braced-init-list, but rather as a
parenthesized expression-list where the initializer list is handed as one
argument. So I'm unsure whether an initializer like `(foo)` should be
regarded as a string literal or not.
I think I will send an issue report about this.
Subsequent discussion with Jason showed that this is covered by 8.5p13:
The form of initialization (using parentheses or =) is generally
insignificant, but does matter when the initializer or the entity
being initialized has a class type;
As this is an array, the text in the Standard in general has to be interpreted
that a = or a (..) initializer are equivalent, unless otherwise stated.
So this is indeed a GCC bug (both that it rejects the member initialization and
the parenthesized non-member initialization).
[Bug lto/48423] crash when using lto, linker plugin with bfd ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-05-14 17:24:12 UTC --- the snapshot ftp://sourceware.org/pub/binutils/snapshots/binutils-2.21.51.tar.bz2 from 14/5/11 5:43:00 AM seems ok for what ld.bdf is concerned (no warning, no crash, export correctly vtable and typeinfo) unwind info is not perfect though: (this is now with gcc version 4.6.1 20110422 (prerelease) (GCC) ld.bdf GNU ld (GNU Binutils) 2.21.51.20110514 (gdb) where #0 0x774d4350 in bhook () from ./plugD.so #1 0x774d3c1b in global constructors keyed to 65535_0_ccXmBt7V.o.3972.2223 () from ./plugD.so #2 0x774d4485 in __do_global_ctors_aux () from ./plugD.so #3 0x774d3a33 in _init () from ./plugD.so #4 0x0036 in ?? () #5 0x00362d60e495 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #6 0x00362d612be2 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #7 0x00362d60e0f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00362d61244a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #9 0x00362de00f66 in dlopen_doit () from /lib64/libdl.so.2 #10 0x00362d60e0f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #11 0x00362de0129c in _dlerror_run () from /lib64/libdl.so.2 #12 0x00362de00ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 #13 0x00401b4d in get () #14 0x00603058 in ?? () #15 0x7fffd78f in ?? () #16 0x00603088 in ?? () #17 0x77b977f3 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const) () from /usr/local/lib64/libstdc++.so.6 #18 0x00401828 in main () --- ld.gold GNU gold (GNU Binutils 2.21.51.20110514) 1.11 (a bit better than before) #0 0x77ad1020 in bhook () from ./plugD.so #1 0x77ad10db in global constructors keyed to 65535_0_ccG5kmS1.o.3972.2223 () from ./plugD.so #2 0x7fffd298 in ?? () #3 0xd030 in ?? () #4 0x7fffd298 in ?? () #5 0x77ad2ad0 in __CTOR_LIST__ () from ./plugD.so #6 0x7fffd260 in ?? () #7 0x00403800 in ?? () #8 0x00403800 in ?? () #9 0x77ad1245 in __do_global_ctors_aux () from ./plugD.so #10 0x77ad07d3 in _init () from ./plugD.so #11 0x0036 in ?? () #12 0x00362d60e495 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #13 0x00362d612be2 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #14 0x00362d60e0f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #15 0x00362d61244a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #16 0x00362de00f66 in dlopen_doit () from /lib64/libdl.so.2 #17 0x00362d60e0f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #18 0x00362de0129c in _dlerror_run () from /lib64/libdl.so.2 #19 0x00362de00ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 #20 0x004016cd in get () #21 0x00401858 in main () ld.bdf from http://www.kernel.org/pub/linux/devel/binutils/binutils-2.21.51.0.8.x86_64.tar.bz2 GNU ld (Linux/GNU Binutils) 2.21.51.0.8.20110408 Breakpoint 1, 0x774d3f30 in bhook () from ./plugD.so Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6_0.5.x86_64 (gdb) where #0 0x774d3f30 in bhook () from ./plugD.so #1 0x774d37fb in global constructors keyed to 65535_0_ccnS2aOK.o.3972.2223 () from ./plugD.so #2 0x774d4065 in __do_global_ctors_aux () from ./plugD.so #3 0x774d3613 in _init () from ./plugD.so #4 0x0036 in ?? () #5 0x00362d60e495 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #6 0x00362d612be2 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #7 0x00362d60e0f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00362d61244a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #9 0x00362de00f66 in dlopen_doit () from /lib64/libdl.so.2 #10 0x00362d60e0f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #11 0x00362de0129c in _dlerror_run () from /lib64/libdl.so.2 #12 0x00362de00ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 #13 0x0040119d in get () #14 0x00400e78 in main ()
[Bug tree-optimization/49000] New: ICE: verify_ssa failed with -O2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49000
Summary: ICE: verify_ssa failed with -O2 -g
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24248
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24248
Output of ajo-gcc -w -O2 -g test1426113557.c -v
This reproduces for me with svn revision 173589 (2011-05-09). It doesn't
reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64.
cat test1426113557.c EOF
static MUL(int ui1, int ui2) {
return (ui1) * (ui2);
}
static int func_60(int *p_61) {
return (*p_61);
}
void func_97() {
int l_234 = 42;
int *l_342 = l_234;
MUL(func_60(l_234), 3);
}
void func_1(void) {
func_97();
}
EOF
gcc -w -O2 -g test1426113557.c
test1426113557.c: In function ‘func_1’:
test1426113557.c:17:1: error: expected an SSA_NAME object
test1426113557.c:17:1: error: in statement
# DEBUG D#1 = l_234
test1426113557.c:17:1: internal compiler error: verify_ssa failed
This test case is reduced from the output of Csmith 2.1.0 (git hash 541a6480,
https://github.com/csmith-project/csmith/), using the following command line:
csmith --no-paranoid --no-longlong --pointers --no-arrays --no-jumps
--no-consts --no-volatiles --checksum --no-divs --muls --no-bitfields
--no-packed-struct -s 1426113557
[Bug target/49001] GCC uses VMOVAPS/PD AVX instructions to access stack variables that are not 32-byte aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001 Norbert Pozar npozar at quick dot cz changed: What|Removed |Added Severity|major |critical
[Bug rtl-optimization/45593] [4.5/4.6 regression] segfault with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2011-05-14 20:39:57 UTC --- Author: danglin Date: Sat May 14 20:39:54 2011 New Revision: 173763 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173763 Log: PR rtl_optimization/48932 Backport from mainline: 2010-09-15 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/45593 * reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit insns that were in delay slots as stand-alone insns. Backport from mainline: 2010-09-15 Eric Botcazou ebotca...@adacore.com * gcc.c-torture/compile/20100915-1.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/20100915-1.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/reorg.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug target/49001] New: GCC uses VMOVAPS/PD AVX instructions to access stack variables that are not 32-byte aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001
Summary: GCC uses VMOVAPS/PD AVX instructions to access stack
variables that are not 32-byte aligned
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: npo...@quick.cz
I'm using a custom mingw64 build of GCC 4.6.1. My target is Windows 64bit. I
compile with g++ -03 -march=corei7-avx -mtune=corei7-avx -mavx.
GCC uses aligned moves VMOVAPS/PD from the new AVX instruction set to access
local variables of type __m256/__m256d on the stack. But the stack pointer is
only 16byte aligned on Win64, so this causes a segmentation fault error when
the stack pointer is not 32byte aligned, as in:
__m256 dummy_ps256;
void test_stackalign32() {
__m256 x = dummy_ps256;
dummy_ps256 = sin256_ps_avx(x);
}
which compiles to
vmovapsdummy_ps256(%rip), %ymm0
leaq32(%rsp), %rdx
vmovaps%ymm0, 32(%rsp) // possible SEGFAULT
leaq64(%rsp), %rcx
vzeroupper
call_Z13sin256_ps_avxDv8_f
vmovaps64(%rsp), %ymm0 // possible SEGFAULT
I couldn't figure out how to realign a stack with -mstackrealign.
[Bug c++/48994] [4.7 regression] [C++0x] error for trivial use of range-based 'for'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48994 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-14 20:37:33 UTC --- I'm testing this change: if (!COMPLETE_TYPE_P (complete_type (TREE_TYPE (range
[Bug fortran/46686] Improve backtracing (unwinding) on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-14 21:11:07 UTC --- (In reply to comment #1) The generic code below relies on libgcc routines, it should work anywhere, doesn't it? Well, on x86-64-linux, I needed at least the following modifications: - #include libgfortran.h - #include stdint.h /* For uintptr_t. */ - On Linux Dl_info does not work by default; as man dladdr states: Glibc adds two functions not described by POSIX, with prototypes #define _GNU_SOURCE /* See feature_test_macros(7) */ #include dlfcn.h one could assume that _GNU_SOURCE had do be defined - but that does not work. With #define __USE_GNU it works - trace_function: The unused parameter gives a fatal warning - thus, I used __attribute__((undefined)). Then it compiles - but linking an executable fails with: undefined reference to `dladdr, unless I link with -ldl. But then I get a backtrace of the form: 0x2af48a719fa7 0x2af48a7e2019 0x400698 0x400688 0x40067d 0x4006a1 0x4006d7 0x2af48b0dbbfd (__libc_start_main) * * * Regarding the functionality * libgo/configure.ac has the check: GCC_CHECK_UNWIND_GETIPINFO Ditto for libada, libjava and libstdc++-v3. Thus, we might pick some functionality from: * libgo/runtime/go-unwind.c * libjava/exception.cc * libjava/stacktrace.cc
[Bug tree-optimization/49002] New: 128-bit AVX load incorrectly becomes 256-bit AVX load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49002 Summary: 128-bit AVX load incorrectly becomes 256-bit AVX load Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ath...@fftw.org Created attachment 24249 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24249 test case for this bug The attached foo.c program contains two 128-bit AVX loads from locations of type __m128d. However, gcc-4.6 converts the first load into a 256-load. While this is semantically correct, because the upper 128-bits are ignored, the vmovapd instruction has different alignment requirements in 128 and 256-bit mode, and therefore this conversion causes spurious segfaults when the data is not 32-byte aligned. Compile the attached program as follows: x86_64-linux-gnu-gcc-4.6 -mavx -O -S foo.c The generated assembly contains the incorrect load: vmovapd (%rdi), %ymm0 By contrast, gcc-4.5 generates the correct 128-bit load instruction vmovapd (%rdi), %xmm0.
[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49000 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.14 23:45:11 CC||iant at google dot com Target Milestone|--- |4.6.1 Summary|ICE: verify_ssa failed with |[4.6/4.7 Regression] ICE: |-O2 -g |verify_ssa failed with -O2 ||-g Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-05-14 23:45:11 UTC --- It is caused by revision 165964: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01151.html
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #13 from ralphengels at gmail dot com ralphengels at gmail dot com 2011-05-15 01:37:13 UTC --- took me quite a while but i found the bug. in gcc/cppspec.c /* If we don't need to edit the command line, we can bail early. */ new_argc = argc + need_E + read_stdin + !!lang_c_here + !!lang_S_here; if (new_argc == argc !o_here) return; new_decoded_options = XNEWVEC (struct cl_decoded_option, new_argc); /* old one */ //new_decoded_options[0] = new_decoded_options[0]; /* new one */ new_decoded_options[0] = decoded_options[0]; i figured it was a bug in command processing after a while so i compared with an older working release and this was what seemed out of place. can you confirm this ?
[Bug c++/49003] New: [C++0x] decltype in member function's trailing return type should deduce constness of *this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49003
Summary: [C++0x] decltype in member function's trailing return
type should deduce constness of *this
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
Now that the resolution of issue #1207
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1207) made it
into the standard, the following example (taken from the same page) should
compile:
struct vector {
struct iterator { };
struct const_iterator { };
iterator begin();
const_iterator begin() const;
};
class block {
vector v;
auto end() const - decltype(v.begin()) { return v.begin(); }
};
Currently, GCC gives the same error as before:
test.cpp: In member function ‘vector::iterator block::end() const’:
test.cpp:9:66: error: could not convert ‘((const
block*)this)-block::v.vector::begin()’ to ‘vector::iterator’
[Bug rtl-optimization/48932] ICE in check_dep, at sched-deps.c:4097
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48932 --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 03:06:35 UTC --- Fixed.
[Bug rtl-optimization/45593] [4.5/4.6 regression] segfault with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 03:04:58 UTC --- Author: danglin Date: Sun May 15 03:04:54 2011 New Revision: 173769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173769 Log: PR rtl-optimization/48932 Backport from mainline: 2010-09-15 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/45593 * reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit insns that were in delay slots as stand-alone insns. Backport from mainline: 2010-09-15 Eric Botcazou ebotca...@adacore.com * gcc.c-torture/compile/20100915-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/20100915-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/reorg.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48932] ICE in check_dep, at sched-deps.c:4097
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48932 --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 03:04:58 UTC --- Author: danglin Date: Sun May 15 03:04:54 2011 New Revision: 173769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173769 Log: PR rtl-optimization/48932 Backport from mainline: 2010-09-15 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/45593 * reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit insns that were in delay slots as stand-alone insns. Backport from mainline: 2010-09-15 Eric Botcazou ebotca...@adacore.com * gcc.c-torture/compile/20100915-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/20100915-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/reorg.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
[Bug c++/49004] New: Improve the error message for linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49004 Summary: Improve the error message for linking failure Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: qiao...@gentoo.org I'm building a C++ shared library project. When I add --coverage to CXXFLAGS, the project fails to compile because libtool uses --nostdlib. The error message is not that helpful: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/variable_printer: hidden symbol `atexit' in /usr/lib64/libc_nonshared.a(atexit.oS) is referenced by DSO /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[1]: *** [variable_printer] Error 1 The message doesn't tell where the hidden symbol is referenced from. I need to run readelf to figure what's going on. I wonder if the error output could be improved to show the information.
