[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-15 09:13:28 UTC --- (In reply to comment #9) Thus, I do not see how one can solve this better than currently done. We might call system() in a separate thread instead of a separate process which is more efficient and would also work on Windows.
[Bug target/38547] duplicate symbols with g++ on AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547 --- Comment #21 from Rainer Tammer tammer at tammer dot net 2011-05-15 09:20:15 UTC --- Hello, Sorry for the delayed answer. On 02.05.2011 19:41, jqian at tibco dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547 --- Comment #20 from Jason Qian jqian at tibco dot com 2011-05-02 17:35:23 UTC --- Comment on attachment 16962 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=16962 errors during build Hi Rainer I got the same message using gcc4.4.0 ob AIX 5.3 Duplicate symbol: .__divti3 Is there patch for this ? Unfortunately not. This problem is there for a long time. But I am not aware of a patch. Bye Rainer
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-15 09:26:02 UTC --- (In reply to comment #11) (In reply to comment #9) Thus, I do not see how one can solve this better than currently done. We might call system() in a separate thread instead of a separate process which is more efficient and would also work on Windows. The drawback is that the calling application would not exit before system() has returned or possibly would abort the running command. So it seems the current implementation is not so bad after all.
[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 URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-05/msg01058.htm ||l --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-15 09:38:56 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01058.html
[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||patch Target Milestone|--- |4.7.0 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 10:04:15 UTC --- patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01059.html
[Bug c++/48999] [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 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-15 10:09:41 UTC --- No ICE with revision 173450, ICE with revision 173451.
[Bug web/46482] [bugzilla] emails not sent to gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46482 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 10:06:18 UTC --- my mails to the gcc, libstdc++, gcc-help and gcc-patches lists show up in the archives almost immediately, so the delays seem to be specific to mails to gcc-bugs generated by bugzilla
[Bug c++/49004] Improve the error message for linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49004 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 10:17:03 UTC --- that error comes from the linker, not gcc
[Bug fortran/48700] [OOP] memory leak with MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 10:30:25 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-05-15 10:30:25 UTC --- (In reply to comment #0) ==25909== 40 bytes in 1 blocks are definitely lost in loss record 3 of 4 ==25909==at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==25909==by 0x401425: MAIN__ (testmv3.f90:37) ==25909==by 0x401729: main (testmv3.f90:22) This guy is due to polymorphic deallocation not working properly yet (cf. PR46321), it is unrelated to MOVE_ALLOC. The component ka, which is allocated by sm%ka=dat%sm%ja, is never freed. We presently only free the components of the declared type, not the dynamic type.
[Bug libfortran/48915] Incorrect process return code with -fdump-core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48915 --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-15 10:23:56 UTC --- Author: jb Date: Sun May 15 10:23:53 2011 New Revision: 173770 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173770 Log: PR 48915 Clarify _gfortran_set_options documentation Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi
[Bug fortran/48700] memory leak with MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[OOP] memory leak with |memory leak with MOVE_ALLOC
|MOVE_ALLOC of polymorphic |
|variables |
--- Comment #2 from janus at gcc dot gnu.org 2011-05-15 11:05:24 UTC ---
(In reply to comment #0)
==25909== 176 (96 direct, 80 indirect) bytes in 1 blocks are definitely lost
in
loss record 4 of 4
==25909==at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==25909==by 0x400DCF: MAIN__ (testmv3.f90:30)
==25909==by 0x401729: main (testmv3.f90:22)
This one indeed seems to be a problem with MOVE_ALLOC, but apparently unrelated
to OOP/polymorphism. Reduced test case:
program testmv3
type bar
integer, allocatable :: ia(:), ja(:)
end type
type(bar), allocatable :: sm,sm2
allocate(sm)
allocate(sm%ia(10),sm%ja(10))
call move_alloc(sm2,sm)
end program testmv3
I think the 80 indirectly lost bytes should be the allocatable components
(40+40), while the 96 are probably their array descriptors (48+48).
The MOVE_ALLOC statement is simply translated to:
sm = sm2;
sm2 = 0B;
We miss to deallocate sm, before it gets overridden.
The standard definitely requires this, because
1) it says that the second argument ('TO') of MOVE_ALLOC is INTENT(OUT), cf.
F08:13.7.118,
2) allocatable INTENT(OUT) arguments must be deallocated upon procedure call,
cf. F08:6.7.3.2.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 ralpheng...@gmail.com ralphengels at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #14 from ralphengels at gmail dot com ralphengels at gmail dot com 2011-05-15 11:20:25 UTC --- well cpp seems to work now so im changing it to fixed unless someone disagress ?.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||mikpe at it dot uu.se --- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2011-05-15 11:32:40 UTC --- Looks like a typo introduced by r163459. Author CC:d. The typo is still present on trunk so I don't think you should have closed this as fixed.
[Bug fortran/48699] [OOP] MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 11:47:17 Ever Confirmed|0 |1 --- Comment #4 from janus at gcc dot gnu.org 2011-05-15 11:47:17 UTC --- (In reply to comment #0) [sfilippo@donald bug31]$ gfortran -c testmv2.f90 testmv2.f90:38.20: call move_alloc(sm,dat%sm) 1 Error: 'from' argument of 'move_alloc' intrinsic at (1) must be ALLOCATABLE Here is a reduced test case for this one: program testmv2 type bar integer, allocatable :: ia(:), ja(:) end type bar class(bar), allocatable :: sm,sm2 allocate(sm2) select type(sm2) type is (bar) call move_alloc(sm2,sm) end select end program testmv2 In each TYPE IS/CLASS IS block we generate a temporary for the selector. Apparently we need to set the correct attributes for the temporary.
[Bug c++/43663] Can't take a const-ref to a bit field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43663
James Dennett james.dennett at gmail dot com changed:
What|Removed |Added
CC||james.dennett at gmail dot
||com
--- Comment #6 from James Dennett james.dennett at gmail dot com 2011-05-15
11:52:01 UTC ---
Here's a quick hack that causes a temporary to be generated when binding a
bit-field to a reference-to-const.
$ svn diff
Index: call.c
===
--- call.c(revision 173769)
+++ call.c(working copy)
@@ -8594,7 +8594,7 @@
expr = error_mark_node;
else
{
- if (!lvalue_or_rvalue_with_address_p (expr))
+ if (is_bitfield_expr_with_lowered_type (expr) ||
!lvalue_or_rvalue_with_address_p (expr))
{
tree init;
var = set_up_extended_ref_temp (decl, expr, cleanup, init);
I'll try to make time to clean that up and add regression tests before running
it by someone with stronger gcc-fu.
[Bug fortran/48699] [OOP] MOVE_ALLOC of polymorphic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #5 from janus at gcc dot gnu.org 2011-05-15 11:53:00 UTC --- (In reply to comment #4) In each TYPE IS/CLASS IS block we generate a temporary for the selector. Apparently we need to set the correct attributes for the temporary. cf. select_type_set_tmp (match.c)
[Bug c++/43663] Can't take a const-ref to a bit field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43663 --- Comment #7 from James Dennett james.dennett at gmail dot com 2011-05-15 11:55:47 UTC --- Unsurprisingly the quick hack isn't really good enough -- it'll happily bind a non-const reference to a temporary initialized from a bitfield. (...and I guess that's why we have tests, and code reviews.)
[Bug fortran/48700] memory leak with MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #3 from janus at gcc dot gnu.org 2011-05-15 12:18:57 UTC --- (In reply to comment #2) We miss to deallocate sm, before it gets overridden. Simple patch which does just that (not regtested): Index: gcc/fortran/trans-intrinsic.c === --- gcc/fortran/trans-intrinsic.c(revision 173579) +++ gcc/fortran/trans-intrinsic.c(working copy) @@ -6961,12 +6961,20 @@ gfc_conv_intrinsic_move_alloc (gfc_code *code) gfc_expr *from, *to; stmtblock_t block; tree tmp; + gfc_se se; from = code-ext.actual-expr; to = code-ext.actual-next-expr; gfc_start_block (block); + /* Deallocate 'TO' argument. */ + gfc_init_se (se, NULL); + se.want_pointer = 1; + gfc_conv_expr (se, to); + tmp = gfc_deallocate_scalar_with_status (se.expr, NULL, true, to, to-ts); + gfc_add_expr_to_block (block, tmp); + if (to-ts.type == BT_CLASS) tmp = gfc_trans_class_assign (to, from, EXEC_POINTER_ASSIGN); else
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 ralpheng...@gmail.com ralphengels at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #16 from ralphengels at gmail dot com ralphengels at gmail dot com 2011-05-15 12:29:29 UTC --- ok ill leave it open. still one bug im running in to but not sure its related to this one. the 64 bit build of 4.6.0 cannot bootstrap itself collect2 ld error 116. the 32 bit one works fine though, i seem to recall hearing it being related to a binutils bug but not sure.
[Bug c++/43663] Can't take a const-ref to a bit field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43663
--- Comment #8 from James Dennett james.dennett at gmail dot com 2011-05-15
12:34:51 UTC ---
Interestingly this works with Apple's g++ 4.2.1, specifically
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3), but
not with their 4.0.1 release.
Tested with:
int main() {
struct S {
S(): i(0) {}
int i : 3;
};
S s;
printf(s: %p\n, (void*)s);
int const cr(s.i); // should compile, binding to a temporary
printf(cr: %p\n, (void*)cr);
}
A non-const reference still correctly gives an error:
st.cc:12: error: invalid initialization of reference of type ‘int’ from
expression of type ‘signed char:3’
[Bug middle-end/48989] [4.7 Regression] FAIL: gfortran.dg/lto/pr46036 f_lto_pr46036_0.o assemble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48989 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-15 12:24:38 UTC --- Presumably everywhere, at least cris-elf too...
[Bug middle-end/46500] target.h includes tm.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46500 --- Comment #8 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2011-05-15 12:51:00 UTC --- Author: amylaar Date: Sun May 15 12:50:57 2011 New Revision: 173771 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173771 Log: PR middle-end/46500 gcc/fortran: * trans-types.c: Include tm.h. [0] (c_size_t_size): Remove. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c
[Bug fortran/48705] [OOP] ALLOCATE with non-trivial SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48705 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 13:08:00 Summary|[OOP] ICE with generic TBP |[OOP] ALLOCATE with ||non-trivial SOURCE Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-05-15 13:08:00 UTC --- Reduced test case: module generic_deferred implicit none type :: addable integer :: i(2) contains procedure :: add end type contains function add(x, y) result(res) class(addable), intent(in) :: x,y class(addable), allocatable :: res allocate(res) res%i = x%i + y%i end function end module program prog use generic_deferred implicit none type(addable) :: x, y class(addable), allocatable :: z x = addable((/1,2/)) y = addable((/2,-2/)) allocate(z,source=add(x,y)) end program prog The ICE comes from the ALLOCATE statement.
[Bug fortran/48700] memory leak with MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700 --- Comment #4 from janus at gcc dot gnu.org 2011-05-15 13:15:23 UTC --- (In reply to comment #3) We miss to deallocate sm, before it gets overridden. Simple patch which does just that (not regtested): Fails at least on move_alloc_2.f90.
[Bug c++/48999] [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 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 13:37:45 UTC --- *** Bug 48907 has been marked as a duplicate of this bug. ***
[Bug middle-end/48907] [4.7 Regression] ICE in bitmap_first_set_bit, at bitmap.c:782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48907 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 13:37:44 UTC --- Duplicate of 48999 which has regression revision. *** This bug has been marked as a duplicate of bug 48999 ***
[Bug c++/48999] [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 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 13:38:24 Ever Confirmed|0 |1
[Bug ada/49005] New: gnattools/Makefile hardcodes gnatmake/gnatbind/gnatlink
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49005 Summary: gnattools/Makefile hardcodes gnatmake/gnatbind/gnatlink Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org When building a cross compiler with Ada enabled you usually need a native compiler of the same version. Toplevel allows overriding CC, GNATMAKE, GNATBIND, but gnattools/Makefile ignores GNATMAKE and GNATBIND, using the tools from PATH instead (which may be the wrong version). GNATLINK needs to be overridable as well, and there is a suspicious use of gnatls.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #48 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-15 16:20:21 UTC --- Author: burnus Date: Sun May 15 16:20:18 2011 New Revision: 173772 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173772 Log: 2011-05-15 Tobias Burnus bur...@net-b.de PR fortran/18918 actual argument is not an array; rank mismatch is diagnosted later. * trans-decl.c (gfc_get_symbol_decl, gfc_trans_deferred_vars): * Handle scalar coarrays. * trans-types.c (gfc_get_array_type_bounds): Ditto. 2011-05-15 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray/image_index_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray/image_index_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug lto/48938] [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48938 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 16:14:06 Ever Confirmed|0 |1 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-05-15 16:14:06 UTC --- It is caused by revision 173517: http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00295.html
[Bug c++/49003] [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 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 17:19:52 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 17:19:52 UTC --- I thought there was already a bug report about this but I can't find it, so confirmed
[Bug fortran/48700] memory leak with MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700
--- Comment #5 from janus at gcc dot gnu.org 2011-05-15 17:23:11 UTC ---
Updated patch:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c(revision 173770)
+++ gcc/fortran/trans-intrinsic.c(working copy)
@@ -6958,15 +6958,27 @@ gfc_conv_intrinsic_move_alloc (gfc_code *code)
if (code-ext.actual-expr-rank == 0)
{
/* Scalar arguments: Generate pointer assignments. */
- gfc_expr *from, *to;
+ gfc_expr *from, *to, *deal;
stmtblock_t block;
tree tmp;
+ gfc_se se;
from = code-ext.actual-expr;
to = code-ext.actual-next-expr;
gfc_start_block (block);
+ /* Deallocate 'TO' argument. */
+ gfc_init_se (se, NULL);
+ se.want_pointer = 1;
+ deal = gfc_copy_expr (to);
+ if (deal-ts.type == BT_CLASS)
+gfc_add_data_component (deal);
+ gfc_conv_expr (se, deal);
+ tmp = gfc_deallocate_scalar_with_status (se.expr, NULL, true,
+ deal, deal-ts);
+ gfc_add_expr_to_block (block, tmp);
+
if (to-ts.type == BT_CLASS)
tmp = gfc_trans_class_assign (to, from, EXEC_POINTER_ASSIGN);
else
[Bug fortran/48705] [OOP] ALLOCATE with non-trivial SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48705 --- Comment #2 from janus at gcc dot gnu.org 2011-05-15 17:40:06 UTC --- (In reply to comment #1) use generic_deferred implicit none type(addable) :: x, y class(addable), allocatable :: z x = addable((/1,2/)) y = addable((/2,-2/)) allocate(z,source=add(x,y)) end program prog The ICE comes from the ALLOCATE statement. I think we'll need to insert a temporary for cases like this, where the SOURCE is not just an EXPR_VARIABLE (cf. gfc_trans_allocate in trans-stmt.c).
[Bug tree-optimization/49006] New: [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 Summary: [4.6/4.7 Regression] Missed vectorization due to revision 167531 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rgue...@gcc.gnu.org Created attachment 24250 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24250 source code On x86_64-apple-darwin10 the attached code (an avatar of the polyhedron test induct.f90) is no longer properly vectorized after revision 167531: [macbook] lin/test% /opt/gcc/gcc4.6p-167530/bin/gfortran -Ofast -ftree-vectorizer-verbose=2 induct_v4.f90 ... induct_v4.f90:1757: note: not vectorized: can't create epilog loop 1. induct_v4.f90:1766: note: LOOP VECTORIZED. induct_v4.f90:1711: note: LOOP VECTORIZED. induct_v4.f90:1633: note: LOOP VECTORIZED. induct_v4.f90:1449: note: vectorized 3 loops in function. induct_v4.f90:2168: note: not vectorized: can't create epilog loop 1. induct_v4.f90:2177: note: LOOP VECTORIZED. induct_v4.f90:2095: note: LOOP VECTORIZED. induct_v4.f90:2018: note: LOOP VECTORIZED. induct_v4.f90:1832: note: vectorized 3 loops in function. ... [macbook] lin/test% time a.out /dev/null 12.677u 0.027s 0:12.70 99.9%0+0k 0+1io 0pf+0w [macbook] lin/test% /opt/gcc/gcc4.6p-167531/bin/gfortran -Ofast -ftree-vectorizer-verbose=2 induct_v4.f90 ... induct_v4.f90:1728: note: not vectorized: unsupported use in stmt. induct_v4.f90:1757: note: not vectorized: unsupported use in stmt. induct_v4.f90:1711: note: LOOP VECTORIZED. induct_v4.f90:1633: note: LOOP VECTORIZED. induct_v4.f90:1449: note: vectorized 2 loops in function. induct_v4.f90:2168: note: not vectorized: unsupported use in stmt. induct_v4.f90:2095: note: LOOP VECTORIZED. induct_v4.f90:2018: note: LOOP VECTORIZED. induct_v4.f90:1832: note: vectorized 2 loops in function. ... [macbook] lin/test% time a.out /dev/null 21.831u 0.031s 0:21.86 100.0%0+0k 0+0io 0pf+0w
[Bug target/49002] 128-bit AVX load incorrectly becomes 256-bit AVX load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49002 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86-avx Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.15 18:28:51 Component|tree-optimization |target CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 Target Milestone|--- |4.6.2 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-05-15 18:28:51 UTC --- Confirmed, caused by r161279 [1],[2]. 2010-06-23 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (bdesc_args): Replace CODE_FOR_avx_si_si256, CODE_FOR_avx_ps_ps256 and CODE_FOR_avx_pd_pd256 with CODE_FOR_vec_extract_lo_v8si, CODE_FOR_vec_extract_lo_v8sf and CODE_FOR_vec_extract_lo_v4df. * config/i386/sse.md (vec_extract_lo_AVX256MODE4P:mode): Changed to define_insn_and_split. (vec_extract_lo_AVX256MODE8P:mode): Likewise. (vec_extract_lo_v16hi): Likewise. (vec_extract_lo_v32qi): Likewise. (avx_avxmodesuffixpavxmodesuffix_avxmodesuffixp): Likewise. (avx_avxmodesuffixp_avxmodesuffixpavxmodesuffix): Removed. [1] http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01197.html [2] http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02216.html
[Bug rtl-optimization/49007] New: ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 Summary: ICE in extract_true_false_edges_from_block at tree-cfg.c:7379 Product: gcc Version: 4.3.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Trunk build fails in stage2 compiling libiberty/regex.c: make[3]: Entering directory `/test/gnu/gcc/objdir.1/libiberty' if [ x-fPIC != x ] [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x-fPIC != x ]; then \ /test/gnu/gcc/objdir.1/./prev-gcc/xgcc -B/test/gnu/gcc/objdir.1/./prev -gcc/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/h ppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/lib/ -isy stem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gc c-4.7/hppa2.0w-hp-hpux11.11/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../. ./gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-proto types -pedantic -fPIC ../../gcc/libiberty/regex.c -o pic/regex.o; \ else true; fi ../../gcc/libiberty/regex.c: In function 'byte_re_match_2_internal': ../../gcc/libiberty/regex.c:8126:1: internal compiler error: vector VEC(edge,bas e) index domain error, in extract_true_false_edges_from_block at tree-cfg.c:7379 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [regex.o] Error 1 # ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.7 --with-gmp=/opt/gnu/gcc/gcc-4.7 --enable-threads=posix --enable-debug=no --disable-nls --without-cloog --without-ppl --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.7.0 20110514 (experimental) [trunk revision 173762] (GCC) Bootstrap: Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enab le-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.3.6 --with-gm p=/opt/gnu/gcc/gcc-4.3.6 --enable-threads=posix --enable-debug=no --disable-nls --enable-checking=release --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.3.6 20110514 (prerelease) [gcc-4_3-branch revision 173762] (GCC) Make command: make STAGE1_CFLAGS=-g -O1 bootstrap This is a gcc-4.3 reorg bug since bootstrap does not fail with -O0 or STAGE1_CFLAGS=-g -O1 -fno-delayed-branch.
[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
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
Severity|critical|normal
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-05-15 18:49:44
UTC ---
(In reply to comment #0)
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.
Please provide testcase that can be compiled without changes. See [1].
FWIW, I have tested following testcase on x86_64-pc-linux-gnu:
--cut here--
#include x86intrin.h
__m256 sin256_ps_avx (__m256);
__m256 dummy_ps256;
void test_stackalign32() {
volatile __m256 x = dummy_ps256;
dummy_ps256 = sin256_ps_avx(x);
}
--cut here--
And got expected code (gcc-4.6.1):
test_stackalign32:
.LFB828:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
subq$32, %rsp
vmovapsdummy_ps256(%rip), %ymm0
vmovaps%ymm0, (%rsp)
vmovaps(%rsp), %ymm0
callsin256_ps_avx
vmovaps%ymm0, dummy_ps256(%rip)
leave
.cfi_def_cfa 7, 8
vzeroupper
ret
Probably mingw64 specific problem... CC added.
[1] http://gcc.gnu.org/bugs/#report
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 21:19:15 UTC --- The then and else labels are the same for the cond: Breakpoint 12, 0x00361cb4 in make_edges () at ../../gcc/gcc/tree-cfg.c:801 801 then_bb = label_to_block (then_label); (gdb) p debug_tree ($r25) label_decl 7ade2630 L.118 type void_type 7af39840 void VOID align 8 symtab 15 alias set -1 canonical type 7af39840 pointer_to_this pointer_type 7af398a0 ignored VOID file line 0 col 0 align 1 context function_decl 7b01c580 byte_re_match_2_internal $22 = void (gdb) c Continuing. Breakpoint 10, 0x00361cb8 in make_edges () at ../../gcc/gcc/tree-cfg.c:801 801 then_bb = label_to_block (then_label); (gdb) disass 0x00361ca8,0x00361cc8 Dump of assembler code from 0x361ca8 to 0x361cc8: 0x00361ca8 make_edges+1040:ldo 3c(r24),r24 0x00361cac make_edges+1044:ldw c(ret0),r5 0x00361cb0 make_edges+1048:b,l 0x35a548 label_to_block_fn,rp 0x00361cb4 make_edges+1052:ldw 0(r9),r26 = 0x00361cb8 make_edges+1056:copy ret0,r4 0x00361cbc make_edges+1060:ldw 0(r9),r26 0x00361cc0 make_edges+1064:b,l 0x35a548 label_to_block_fn,rp 0x00361cc4 make_edges+1068:copy r5,r25 End of assembler dump. (gdb) p debug_tree ($r5) label_decl 7ade2630 L.118 type void_type 7af39840 void VOID align 8 symtab 15 alias set -1 canonical type 7af39840 pointer_to_this pointer_type 7af398a0 ignored VOID file line 0 col 0 align 1 context function_decl 7b01c580 byte_re_match_2_internal $23 = void
[Bug target/48554] Regression for coldfire platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554 Vincent Riviere vincent.riviere at freesbee dot fr changed: What|Removed |Added CC||vincent.riviere at freesbee ||dot fr --- Comment #2 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-05-15 21:11:48 UTC --- This bug looks similar to PR 47612.
[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 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-05-15 22:10:00 UTC --- Stack alignment isn't supported on Windows.
[Bug fortran/48700] memory leak with MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700 --- Comment #6 from janus at gcc dot gnu.org 2011-05-15 22:05:00 UTC --- The patch in comment #5 regtests cleanly. But apparently there is also a problem with MOVE_ALLOC and allocatable arrays: program testmv3 type bar integer, allocatable :: ia(:), ja(:) end type type(bar), allocatable :: sm(:),sm2(:) allocate(sm(1)) allocate(sm(1)%ia(10),sm(1)%ja(10)) call move_alloc(sm2,sm) end program testmv3 valgrind shows that the allocatable components are not being freed: ==21249== 40 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==21249==at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21249==by 0x400B8F: MAIN__ (arr.f90:10) ==21249==by 0x400FE6: main (arr.f90:14) ==21249== ==21249== 40 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==21249==at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21249==by 0x400CF4: MAIN__ (arr.f90:10) ==21249==by 0x400FE6: main (arr.f90:14)
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2011-05-15 22:26:47 UTC --- Breakpoint 5, make_cond_expr_edges (bb=0x7ac36b40) at ../../gcc/gcc/tree-cfg.c:793 793 gcc_assert (entry); (gdb) p debug_gimple_stmt ($ret0) if (regstart != 0B) goto L118; else goto L118;
[Bug rtl-optimization/48633] [4.7 regression] IRA causes ICE in compensate_edge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-05-15 22:55:59 UTC --- The same error is triggered with the testcase in PR 48757.
[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 #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 23:08:00 UTC --- fixed
[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 #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 23:04:06 UTC --- Author: redi Date: Sun May 15 23:04:04 2011 New Revision: 173778 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173778 Log: PR c++/48994 * parser.c (cp_parser_perform_range_for_lookup): Call complete_type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/range-for18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #10 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-05-15 22:58:15 UTC --- Author: hjl Date: Sun May 15 22:58:13 2011 New Revision: 173777 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173777 Log: Rename tls_global_dynamic_64 to tls_global_dynamic_64_mode. 2011-05-13 H.J. Lu hongjiu...@intel.com PR target/47715 * config/i386/i386.md (PTR64): New. (*tls_global_dynamic_64): Rename to ... (*tls_global_dynamic_64_mode): This. Put PTR64 on operand 1. (tls_global_dynamic_64): Rename to ... (tls_global_dynamic_64_mode): This. Put PTR64 on operand 1. * config/i386/i386.c (legitimize_tls_address): Updated. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/config/i386/i386.c branches/x32/gcc/config/i386/i386.md
[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 Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-15 23:08:37 UTC --- fixed (and actually change the status this time!)
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2011-05-16 01:35:28 UTC --- By trial and error, it appears tree-cfgcleanup.c is miscompiled at -O1 without -fno-delayed-branch.
[Bug c++/49004] Improve the error message for linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49004 Paul Carroll pcarroll at codesourcery dot com changed: What|Removed |Added CC||pcarroll at codesourcery ||dot com --- Comment #2 from Paul Carroll pcarroll at codesourcery dot com 2011-05-16 05:34:55 UTC --- There is at least one way to modify the binutils linker to find the name of the DSO that contains the hidden symbol reference. The solution I implemented last month hasn't been reviewed yet, so I have not gotten any feedback on whether it is acceptable or not to put into ld.
