[Bug fortran/29606] Internal Error: Derived type I/O should have been handled via the frontend
--- Comment #3 from pault at gcc dot gnu dot org 2007-09-16 09:18 --- Subject: Bug 29606 Author: pault Date: Sun Sep 16 09:17:49 2007 New Revision: 128523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128523 Log: 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * trans.h : Add extra argument to gfc_build_array_ref. Rename gfc_conv_aliased_arg to gfc_conv_subref_array_arg. Move prototype of is_aliased_array to gfortran.h and rename it gfc_is_subref_array. Add field span to lang_decl, add a new decl lang specific flag accessed by GFC_DECL_SUBREF_ARRAY_P and a new type flag GFC_DECL_SUBREF_ARRAY_P. * trans.c (gfc_build_array_ref): Add the new argument, decl. If this is a subreference array pointer, use the lang_decl field 'span' to calculate the offset in bytes and use pointer arithmetic to address the element. * trans-array.c (gfc_conv_scalarized_array_ref, gfc_conv_array_ref): Add the backend declaration as the third field, if it is likely to be a subreference array pointer. (gfc_conv_descriptor_dimension, gfc_trans_array_ctor_element, gfc_trans_array_constructor_element, structure_alloc_comps, gfc_conv_array_index_offset): For all other references to gfc_build_array_ref, set the third argument to NULL. (gfc_get_dataptr_offset): New function. (gfc_conv_expr_descriptor): If the rhs of a pointer assignment is a subreference array, then calculate the offset to the subreference of the first element and set the descriptor data pointer to this, using gfc_get_dataptr_offset. trans-expr.c (gfc_get_expr_charlen): Use the expression for the character length for a character subreference. (gfc_conv_substring, gfc_conv_subref_array_arg): Add NULL for third argument in call to gfc_build_array_ref. (gfc_conv_aliased_arg): Rename to gfc_conv_subref_array_arg. (is_aliased_array): Remove. (gfc_conv_function_call): Change reference to is_aliased_array to gfc_is_subref_array and reference to gfc_conv_aliased_arg to gfc_conv_subref_array_arg. (gfc_trans_pointer_assignment): Add the array element length to the lang_decl 'span' field. * gfortran.h : Add subref_array_pointer to symbol_attribute and add the prototype for gfc_is_subref_array. * trans-stmt.c : Add NULL for third argument in all references to gfc_build_array_ref. * expr.c (gfc_is_subref_array): Renamed is_aliased_array. If this is a subreference array pointer, return true. (gfc_check_pointer_assign): If the rhs is a subreference array, set the lhs subreference_array_pointer attribute. * trans-decl.c (gfc_get_symbol_decl): Allocate the lang_decl field if the symbol is a subreference array pointer and set an initial value of zero for the 'span' field. * trans-io.c (set_internal_unit): Refer to is_subref_array and gfc_conv_subref_array_arg. (nml_get_addr_expr): Add NULL third argument to gfc_build_array_ref. (gfc_trans_transfer): Use the scalarizer for a subreference array. 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * gfortran.dg/subref_array_pointer_1.f90: New test. * gfortran.dg/subref_array_pointer_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29606
[Bug fortran/29396] segfault with character pointer association
--- Comment #8 from pault at gcc dot gnu dot org 2007-09-16 09:18 --- Subject: Bug 29396 Author: pault Date: Sun Sep 16 09:17:49 2007 New Revision: 128523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128523 Log: 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * trans.h : Add extra argument to gfc_build_array_ref. Rename gfc_conv_aliased_arg to gfc_conv_subref_array_arg. Move prototype of is_aliased_array to gfortran.h and rename it gfc_is_subref_array. Add field span to lang_decl, add a new decl lang specific flag accessed by GFC_DECL_SUBREF_ARRAY_P and a new type flag GFC_DECL_SUBREF_ARRAY_P. * trans.c (gfc_build_array_ref): Add the new argument, decl. If this is a subreference array pointer, use the lang_decl field 'span' to calculate the offset in bytes and use pointer arithmetic to address the element. * trans-array.c (gfc_conv_scalarized_array_ref, gfc_conv_array_ref): Add the backend declaration as the third field, if it is likely to be a subreference array pointer. (gfc_conv_descriptor_dimension, gfc_trans_array_ctor_element, gfc_trans_array_constructor_element, structure_alloc_comps, gfc_conv_array_index_offset): For all other references to gfc_build_array_ref, set the third argument to NULL. (gfc_get_dataptr_offset): New function. (gfc_conv_expr_descriptor): If the rhs of a pointer assignment is a subreference array, then calculate the offset to the subreference of the first element and set the descriptor data pointer to this, using gfc_get_dataptr_offset. trans-expr.c (gfc_get_expr_charlen): Use the expression for the character length for a character subreference. (gfc_conv_substring, gfc_conv_subref_array_arg): Add NULL for third argument in call to gfc_build_array_ref. (gfc_conv_aliased_arg): Rename to gfc_conv_subref_array_arg. (is_aliased_array): Remove. (gfc_conv_function_call): Change reference to is_aliased_array to gfc_is_subref_array and reference to gfc_conv_aliased_arg to gfc_conv_subref_array_arg. (gfc_trans_pointer_assignment): Add the array element length to the lang_decl 'span' field. * gfortran.h : Add subref_array_pointer to symbol_attribute and add the prototype for gfc_is_subref_array. * trans-stmt.c : Add NULL for third argument in all references to gfc_build_array_ref. * expr.c (gfc_is_subref_array): Renamed is_aliased_array. If this is a subreference array pointer, return true. (gfc_check_pointer_assign): If the rhs is a subreference array, set the lhs subreference_array_pointer attribute. * trans-decl.c (gfc_get_symbol_decl): Allocate the lang_decl field if the symbol is a subreference array pointer and set an initial value of zero for the 'span' field. * trans-io.c (set_internal_unit): Refer to is_subref_array and gfc_conv_subref_array_arg. (nml_get_addr_expr): Add NULL third argument to gfc_build_array_ref. (gfc_trans_transfer): Use the scalarizer for a subreference array. 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * gfortran.dg/subref_array_pointer_1.f90: New test. * gfortran.dg/subref_array_pointer_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #10 from pault at gcc dot gnu dot org 2007-09-16 09:18 --- Subject: Bug 30625 Author: pault Date: Sun Sep 16 09:17:49 2007 New Revision: 128523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128523 Log: 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * trans.h : Add extra argument to gfc_build_array_ref. Rename gfc_conv_aliased_arg to gfc_conv_subref_array_arg. Move prototype of is_aliased_array to gfortran.h and rename it gfc_is_subref_array. Add field span to lang_decl, add a new decl lang specific flag accessed by GFC_DECL_SUBREF_ARRAY_P and a new type flag GFC_DECL_SUBREF_ARRAY_P. * trans.c (gfc_build_array_ref): Add the new argument, decl. If this is a subreference array pointer, use the lang_decl field 'span' to calculate the offset in bytes and use pointer arithmetic to address the element. * trans-array.c (gfc_conv_scalarized_array_ref, gfc_conv_array_ref): Add the backend declaration as the third field, if it is likely to be a subreference array pointer. (gfc_conv_descriptor_dimension, gfc_trans_array_ctor_element, gfc_trans_array_constructor_element, structure_alloc_comps, gfc_conv_array_index_offset): For all other references to gfc_build_array_ref, set the third argument to NULL. (gfc_get_dataptr_offset): New function. (gfc_conv_expr_descriptor): If the rhs of a pointer assignment is a subreference array, then calculate the offset to the subreference of the first element and set the descriptor data pointer to this, using gfc_get_dataptr_offset. trans-expr.c (gfc_get_expr_charlen): Use the expression for the character length for a character subreference. (gfc_conv_substring, gfc_conv_subref_array_arg): Add NULL for third argument in call to gfc_build_array_ref. (gfc_conv_aliased_arg): Rename to gfc_conv_subref_array_arg. (is_aliased_array): Remove. (gfc_conv_function_call): Change reference to is_aliased_array to gfc_is_subref_array and reference to gfc_conv_aliased_arg to gfc_conv_subref_array_arg. (gfc_trans_pointer_assignment): Add the array element length to the lang_decl 'span' field. * gfortran.h : Add subref_array_pointer to symbol_attribute and add the prototype for gfc_is_subref_array. * trans-stmt.c : Add NULL for third argument in all references to gfc_build_array_ref. * expr.c (gfc_is_subref_array): Renamed is_aliased_array. If this is a subreference array pointer, return true. (gfc_check_pointer_assign): If the rhs is a subreference array, set the lhs subreference_array_pointer attribute. * trans-decl.c (gfc_get_symbol_decl): Allocate the lang_decl field if the symbol is a subreference array pointer and set an initial value of zero for the 'span' field. * trans-io.c (set_internal_unit): Refer to is_subref_array and gfc_conv_subref_array_arg. (nml_get_addr_expr): Add NULL third argument to gfc_build_array_ref. (gfc_trans_transfer): Use the scalarizer for a subreference array. 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * gfortran.dg/subref_array_pointer_1.f90: New test. * gfortran.dg/subref_array_pointer_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug fortran/30871] Pointer to substring rejected with Different character lengths in pointer assignment
--- Comment #4 from pault at gcc dot gnu dot org 2007-09-16 09:18 --- Subject: Bug 30871 Author: pault Date: Sun Sep 16 09:17:49 2007 New Revision: 128523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128523 Log: 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * trans.h : Add extra argument to gfc_build_array_ref. Rename gfc_conv_aliased_arg to gfc_conv_subref_array_arg. Move prototype of is_aliased_array to gfortran.h and rename it gfc_is_subref_array. Add field span to lang_decl, add a new decl lang specific flag accessed by GFC_DECL_SUBREF_ARRAY_P and a new type flag GFC_DECL_SUBREF_ARRAY_P. * trans.c (gfc_build_array_ref): Add the new argument, decl. If this is a subreference array pointer, use the lang_decl field 'span' to calculate the offset in bytes and use pointer arithmetic to address the element. * trans-array.c (gfc_conv_scalarized_array_ref, gfc_conv_array_ref): Add the backend declaration as the third field, if it is likely to be a subreference array pointer. (gfc_conv_descriptor_dimension, gfc_trans_array_ctor_element, gfc_trans_array_constructor_element, structure_alloc_comps, gfc_conv_array_index_offset): For all other references to gfc_build_array_ref, set the third argument to NULL. (gfc_get_dataptr_offset): New function. (gfc_conv_expr_descriptor): If the rhs of a pointer assignment is a subreference array, then calculate the offset to the subreference of the first element and set the descriptor data pointer to this, using gfc_get_dataptr_offset. trans-expr.c (gfc_get_expr_charlen): Use the expression for the character length for a character subreference. (gfc_conv_substring, gfc_conv_subref_array_arg): Add NULL for third argument in call to gfc_build_array_ref. (gfc_conv_aliased_arg): Rename to gfc_conv_subref_array_arg. (is_aliased_array): Remove. (gfc_conv_function_call): Change reference to is_aliased_array to gfc_is_subref_array and reference to gfc_conv_aliased_arg to gfc_conv_subref_array_arg. (gfc_trans_pointer_assignment): Add the array element length to the lang_decl 'span' field. * gfortran.h : Add subref_array_pointer to symbol_attribute and add the prototype for gfc_is_subref_array. * trans-stmt.c : Add NULL for third argument in all references to gfc_build_array_ref. * expr.c (gfc_is_subref_array): Renamed is_aliased_array. If this is a subreference array pointer, return true. (gfc_check_pointer_assign): If the rhs is a subreference array, set the lhs subreference_array_pointer attribute. * trans-decl.c (gfc_get_symbol_decl): Allocate the lang_decl field if the symbol is a subreference array pointer and set an initial value of zero for the 'span' field. * trans-io.c (set_internal_unit): Refer to is_subref_array and gfc_conv_subref_array_arg. (nml_get_addr_expr): Add NULL third argument to gfc_build_array_ref. (gfc_trans_transfer): Use the scalarizer for a subreference array. 2007-09-16 Paul Thomas [EMAIL PROTECTED] PR fortran/29396 PR fortran/29606 PR fortran/30625 PR fortran/30871 * gfortran.dg/subref_array_pointer_1.f90: New test. * gfortran.dg/subref_array_pointer_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug fortran/30871] Pointer to substring rejected with Different character lengths in pointer assignment
--- Comment #5 from pault at gcc dot gnu dot org 2007-09-16 09:39 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug fortran/30625] Array pointers to components of derived type arrays do not work
--- Comment #11 from pault at gcc dot gnu dot org 2007-09-16 09:39 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug fortran/29606] Internal Error: Derived type I/O should have been handled via the frontend
--- Comment #4 from pault at gcc dot gnu dot org 2007-09-16 09:40 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29606
[Bug fortran/29396] segfault with character pointer association
--- Comment #9 from pault at gcc dot gnu dot org 2007-09-16 09:40 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug fortran/33337] [4.3 regression] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:510
--- Comment #3 from pault at gcc dot gnu dot org 2007-09-16 09:42 --- As the guilty party, I had better take this on. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-08 11:40:29 |2007-09-16 09:42:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
[Bug tree-optimization/33434] [4.3 Regression] -fipa-cp miscompilation
--- Comment #1 from razya at il dot ibm dot com 2007-09-16 10:38 ---
(In reply to comment #0)
Found this while trying to bootstrap with BOOT_CFLAGS=-O3 -fipa-cp and it
miscompiled libcpp/macro.c at the stage2. Appeared somewhere in between
r122374 and r124593:
/* { dg-do run } */
/* { dg-options -O3 -fipa-cp } */
int k;
void f1 (int a, int b)
{
if (a)
while (b --)
k = 1;
else
if (b != 1)
__builtin_abort ();
}
int main (void)
{
f1 (1, 1);
if (k != 1)
__builtin_abort ();
return 0;
}
Looking into it. Razya
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug tree-optimization/33447] New: Non-empty latch block prevents loop vectorization
The following loop (from linpk.f90) contains a non-empty latch block before tree optimizations: Source code: Line m = MOD(N,4) 323IF ( m.NE.0 ) THEN 324 DO i = 1 , m 325 Dy(i) = Dy(i) + Da*Dx(i) 326 ENDDO 327 IF ( N.LT.4 ) RETURN 328ENDIF 329mp1 = m + 1 330DO i = mp1 , N , 4 331 Dy(i) = Dy(i) + Da*Dx(i) 332 Dy(i+1) = Dy(i+1) + Da*Dx(i+1) 333 Dy(i+2) = Dy(i+2) + Da*Dx(i+2) 334 Dy(i+3) = Dy(i+3) + Da*Dx(i+3) 335ENDDO The first SSA dump: bb 17: ... if (countm1.32_8 == 0) goto bb 19; else goto bb 18; bb 18: countm1.32_98 = countm1.32_8 + 4294967295; goto bb 17; This is also related to PR 28643 and PR 33244. However, in these PRs some tree optimization puts stmts/phi nodes in the latch block, while in the lnpck example the latch block is non-empty to begin with. -- Summary: Non-empty latch block prevents loop vectorization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33447
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #15 from rask at gcc dot gnu dot org 2007-09-16 12:57 --- 1. You should use define_insn_and_split. 2. If possible (which I think it is here), splitting before reload should produc.e better code. Btw, what is the ICE? Also, it seems to me that avr.h defines MOVE_MAX incorrectly. Shouldn't it be 2 instead of 4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug tree-optimization/33319] [4.2/4.3 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-09-16 13:28 --- Also fails on amd64 linux. gcc 4.2 with -O1 -ftree-vectorize error message is: pr27549.C: In function 'const char* foo()': pr27549.C:72: internal compiler error: in coalesce_abnormal_edges, at tree-outof-ssa.c:643 Maybe related to bug 31081 (doesn't fail with -fno-inline). -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-linux | GCC host triplet|powerpc-linux | GCC target triplet|powerpc-linux | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-09-16 13:28:35 date|| Summary|ICE with vectorization in |[4.2/4.3 regression] |the testauite |g++.dg/tree-ssa/pr27549.C ||ICE with vectorization Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #16 from rask at gcc dot gnu dot org 2007-09-16 13:38 --- Created an attachment (id=14211) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14211action=view) quick and dirty patch to reduce code size A fundamental problem with the AVR back end is that it sabotages the RTL optimizer's attempts to optimize away redundant move insns. With this patch, I get better code (-O2): foo: push r29 ; 73 *pushhi/1 [length = 2] push r28 rcall . ; 79 *addhi3_sp_R_pc2[length = 3] rcall . rcall . in r28,__SP_L__ ; 90 *movqi/6[length = 1] in r29,__SP_H__ ; 91 *movqi/6[length = 1] /* prologue: function */ /* frame size = 6 */ ldi r24,lo8(2) ; 68 *movqi/2[length = 1] std Y+5,r24 ; 70 *movqi/3[length = 1] std Y+6,__zero_reg__ ; 71 *movqi/3[length = 1] ldi r22,lo8(2) ; 21 *movqi/2[length = 1] ldi r23,lo8(0) ; 23 *movqi/2[length = 1] ldi r18,lo8(1) ; 42 *movqi/2[length = 1] ldi r19,lo8(0) ; 43 *movqi/2[length = 1] ldi r20,lo8(0) ; 44 *movqi/2[length = 1] ldi r21,lo8(0) ; 45 *movqi/2[length = 1] ldi r24,lo8(0) ; 48 *movqi/2[length = 1] ldi r25,lo8(0) ; 49 *movqi/2[length = 1] /* epilogue start */ adiw r28,6 ; 85 *addhi3/2 [length = 1] out __SP_L__,r28 ; 92 *movqi/5[length = 1] out __SP_H__,r29 ; 93 *movqi/5[length = 1] pop r28 ; 87 pophi [length = 2] pop r29 ret ; 88 return_from_epilogue[length = 1] .size foo, .-foo /* File /home/rask/pr11180.c: code0 = 0x ( 0), prologues 0, epilogues 0 */ Perhaps a peephole optimization could replace insns 48 and 49 with movw r25:r24, r21:r20. The only big further improvement I see would be to get rid of the stack var. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #17 from rask at gcc dot gnu dot org 2007-09-16 13:54 --- The patch is against mainline revision 128431. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #4 from jb at gcc dot gnu dot org 2007-09-16 14:12 --- (In reply to comment #3) Why marking this as blocking asynchronous I/O? Well, no hard dependency. I just thought it would make sense to do this first, as it would reduce the work required to convert the library to a more traditional read/write design. I'm sure it's possible to shoehorn async i/o into the current library as well. Especially as there is no point in adding support for real async i/o at the moment, since e.g. Linux supports it only in conjunction with direct I/O. Frontend syntax support can be added before the actual backend takes advantage of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug middle-end/33448] New: [4.1/4.2/4.3] ICE in create_tmp_var, at gimplify.c:487
[forwarded from http://bugs.debian.org/439687] seen with 4.1, 4,2, 4,3. $ gcc -c statusfile.i stdin: In function 'pa_notavail': stdin:100: internal compiler error: in create_tmp_var, at gimplify.c:487 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.1/4.2/4.3] ICE in create_tmp_var, at gimplify.c:487 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33448
[Bug middle-end/33448] [4.1/4.2/4.3] ICE in create_tmp_var, at gimplify.c:487
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-09-16 14:52 --- Created an attachment (id=14212) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14212action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33448
[Bug middle-end/33448] [4.1/4.2/4.3] ICE in create_tmp_var, at gimplify.c:487
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-16 15:08 --- This code is invalid. The enum type is not declared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33448
[Bug middle-end/33448] [4.1/4.2/4.3] ICE in create_tmp_var, at gimplify.c:487
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-16 15:09 --- *** This bug has been marked as a duplicate of 32295 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33448
[Bug c/32295] [4.1/4.2/4.3 Regression] An invalid c code causes an ICE in create_tmp_var, at gimplify.c:489
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-16 15:09 --- *** Bug 33448 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32295
[Bug middle-end/33448] [4.1/4.2/4.3] ICE in create_tmp_var, at gimplify.c:487
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-16 15:12 --- static enum parsedb pa_flags; I think parsedb really should parsedbflags here but I could be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33448
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #18 from eweddington at cso dot atmel dot com 2007-09-16 15:44 --- Subject: RE: [avr-gcc] Optimization decrease performance of struct assignment. --- Comment #15 from rask at gcc dot gnu dot org 2007-09-16 12:57 --- Also, it seems to me that avr.h defines MOVE_MAX incorrectly. Shouldn't it be 2 instead of 4? Hmm. Yes and no. There are variants that have the MOVW instruction, and for those it should be 2. Otherwise, if they don't have the MOVW instruction, it should be 1, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug c++/32756] [4.3 Regression] wrong ambiguous overload error?
--- Comment #7 from nathan at gcc dot gnu dot org 2007-09-16 17:26 --- Subject: Bug 32756 Author: nathan Date: Sun Sep 16 17:26:42 2007 New Revision: 128528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128528 Log: cp/ PR c++/32756 * call.c (maybe_handle_implicit_object): Set this_p, clear rvaluedness_matches_p. (compare_ics): Do not compare rvaluedness matching when one of the operands is an implicit object. testsuite/ PR c++/32756 * g++.dg/overload/operator3.C: New. Added: trunk/gcc/testsuite/g++.dg/overload/operator3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #19 from rask at gcc dot gnu dot org 2007-09-16 17:30 ---
Created an attachment (id=14213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14213action=view)
quick and dirty patch to reduce code size
Here's a patch which doesn't mess up the stack pointer update in the epilogue.
The code size output is broken on mainline, so here's what I use:
$ gcc/xgcc -Bgcc/ -W -Wall ~/pr11180.c -S -dp -o /dev/stdout -O2 | awk
'match($0, /\[length = ([[:digit:]]+)\]/, field) { sum += field[1]; } END {
print sum; }'
27
Compare that to unpatched mainline:
$ gcc/xgcc -Bgcc/ -W -Wall ~/pr11180.c -S -dp -o /dev/stdout -O2 | awk
'match($0, /\[length = ([[:digit:]]+)\]/, field) { sum += field[1]; } END {
print sum; }'
36
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #14211|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug fortran/33449] New: ice for fortran code with -O2 -ftree-vectorize
I just tried to compile lapack version 3.1.1 with the GNU Fortran compiler version 4.3 snapshot 20070914. The compiler said /home/dcb/gcc/20070914/results/bin/gfortran -g -O3 -Wall -ftree-vectorize -c dlarre.f -o dlarre.o dlarre.f: In function 'dlarre': dlarre.f:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Here is some help from valgrind ==32315== Invalid read of size 4 ==32315==at 0xAB06EA: vect_get_vec_defs_for_stmt_copy (tree.h:210) ==32315==by 0xAB3CC5: vectorizable_operation (tree-vect-transform.c:3987) ==32315==by 0xAC058B: vect_transform_stmt (tree-vect-transform.c:6095) ==32315==by 0xAC1707: vect_transform_loop (tree-vect-transform.c:7334) ==32315==by 0x80766B: vectorize_loops (tree-vectorizer.c:2507) ==32315==by 0x64BCC8: execute_one_pass (passes.c:1115) ==32315==by 0x64BE9F: execute_pass_list (passes.c:1168) ==32315==by 0x64BEB4: execute_pass_list (passes.c:1169) ==32315==by 0x64BEB4: execute_pass_list (passes.c:1169) ==32315==by 0x72480F: tree_rest_of_compilation (tree-optimize.c:404) ==32315==by 0x893DD3: cgraph_expand_function (cgraphunit.c:1070) ==32315==by 0x896024: cgraph_optimize (cgraphunit.c:1139) ==32315== Address 0x0 is not stack'd, malloc'd or (recently) free'd dlarre.f: In function 'dlarre': dlarre.f:1: internal compiler error: Segmentation fault Source attached. Flags -O2 -ftree-vectorize required. -- Summary: ice for fortran code with -O2 -ftree-vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug fortran/33449] ice for fortran code with -O2 -ftree-vectorize
--- Comment #1 from dcb314 at hotmail dot com 2007-09-16 18:18 --- Created an attachment (id=14214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14214action=view) fortran source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug fortran/33449] ice for fortran code with -O2 -ftree-vectorize
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-09-16 18:30 --- I'm not seeing this problem on powerpc-apple-darwin9. I am using a svn pull from gcc trunk that has the ICE fixes Dorit added in... r128514 | dorit | 2007-09-15 14:24:23 -0400 (Sat, 15 Sep 2007) | 7 lines * tree-vect-transform.c (vect_get_vec_defs_for_stmt_copy): check if the VEC is not NULL. (vectorizable_type_demotion, vectorizable_type_promotion): Check that get_vectype_for_scalar_type succeeded. (vectorizable_conversion): Likewise. You might want to try again with the current gcc trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33449
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #8 from andreast at gcc dot gnu dot org 2007-09-16 19:09 --- enable-checking is always used on development trees which trunk belongs to. I usually do build with disable-checking. And with disable-checking you do not see the bug. In comment #5 I only wanted to state that now I see the break as well. It is impossible to get some preprocessed source from this break since it does not preprocess anything. It is a .class to .o compilation. I'll try my best to get some more details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #9 from dominiq at lps dot ens dot fr 2007-09-16 19:55 --- It is impossible to get some preprocessed source from this break since it does not preprocess anything. It is a .class to .o compilation. May be you could have a look at the reduced code in PR 33348. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug target/24547] Branch cost of -Os is ignored
--- Comment #3 from steven at gcc dot gnu dot org 2007-09-16 21:22 --- Won't fix for GCC 4.1. Fixed since GCC 4.2. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.1.0 Known to work||4.2.0 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24547
[Bug rtl-optimization/33450] New: Optimization with -O3 and -O2 producing bad code
I have tested this code with many version of GCC, three under Linux x86 PC and
one into x86 Mac OS X.
This bug appears with version 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9),
in a Gentoo x86_64 Linux PC, and with Gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) and
4.1.2 20061115 (prerelease) (Debian 4.1.1-21).
It doesn't appear in x86 Mac Os X 10.4 with version 4.0.1 (Apple Computer,
Inc. build 5250)
This very simple code show the gcc's bug.
#include stdio.h // for printf
struct ELT {
int item;
} one_elt;
int main()
{ struct ELT *two_elt;
long *src,*dst;
two_elt = malloc(sizeof(struct ELT));
src = (long *)one_elt;
dst = (long *)two_elt;
dst[0] = src[0];
two_elt-item = 27;
malloc(2);
printf(27 = %d\n,two_elt-item);
return( 0);
}
When you compile with -O1 or -O0, we get 27=27, but when we compile with -O2
or -O3 switch, we get 27=0
Gcc forget code's dependancy.
--
Summary: Optimization with -O3 and -O2 producing bad code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ontologiae at gmail dot com
GCC build triplet: x86 and x86_64-linux-pc-gnu
GCC host triplet: x86 and x86_64-linux-pc-gnu
GCC target triplet: x86 and x86_64-linux-pc-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33450
[Bug rtl-optimization/33450] Optimization with -O3 and -O2 producing bad code
--- Comment #1 from ontologiae at gmail dot com 2007-09-16 21:26 --- Created an attachment (id=14215) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14215action=view) Preprocessed file that show the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33450
[Bug middle-end/33348] [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-09-16 21:52 --- What happens in this testcase is (mis)behaviour of invariant code motion. On instruction: (set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) (const_int 80 [0x50])) [3 S4 A32]) (fix:SI (reg:DF 135))) the invariant code is trying to replace the write-load pair, however the truncsfdf2 expander is expanding fix from reg to reg will offload the value to memory again, so we are replacing load by: (insn 44 0 45 (parallel [ (set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) (const_int 84 [0x54])) [3 S4 A32]) (fix:SI (reg:DF 135))) (clobber (reg:DI 138)) ]) -1 (nil)) (insn 45 44 46 (set (reg:SI 137) (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) (const_int 84 [0x54])) [3 S4 A32])) -1 (expr_list:REG_EQUAL (fix:SI (reg:DF 135)) (nil))) (insn 46 45 0 (set (reg:SI 136) (reg:SI 137)) -1 (nil)) This is not very sane transformation at all IMO. Zdenek, perhaps we can disable the transform, when force_operand produces a memory load or some similar lame trick? Anyway, the sharing problem is cured by: Index: loop-invariant.c === *** loop-invariant.c(revision 128492) --- loop-invariant.c(working copy) *** move_invariant_reg (struct loop *loop, u *** 1243,1248 --- 1243,1249 if (op != reg) emit_move_insn (reg, op); seq = get_insns (); + unshare_all_rtl_in_chain (seq); end_sequence (); if (!seq_insns_valid_p (seq)) I will commit as obvious if testing passes. Still I would hope we can also avoid loop from doing this transform at all. Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-16 21:52:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
[Bug middle-end/33348] [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2007-09-16 22:07 --- Subject: Re: [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1 What happens in this testcase is (mis)behaviour of invariant code motion. On instruction: (set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) (const_int 80 [0x50])) [3 S4 A32]) (fix:SI (reg:DF 135))) the invariant code is trying to replace the write-load pair, however the truncsfdf2 expander is expanding fix from reg to reg will offload the value to memory again, so we are replacing load by: (insn 44 0 45 (parallel [ (set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) (const_int 84 [0x54])) [3 S4 A32]) (fix:SI (reg:DF 135))) (clobber (reg:DI 138)) ]) -1 (nil)) (insn 45 44 46 (set (reg:SI 137) (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) (const_int 84 [0x54])) [3 S4 A32])) -1 (expr_list:REG_EQUAL (fix:SI (reg:DF 135)) (nil))) (insn 46 45 0 (set (reg:SI 136) (reg:SI 137)) -1 (nil)) This is not very sane transformation at all IMO. Actually, it may make some sense -- the newly generated memory store load are outside of the loop; so the code inside the loop is simplified, and in some cases we might even avoid memory accesses inside the loop. Nevertheless, force_operand in move_invariant_reg causes other problems as well, so I guess I will remove this code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
[Bug c++/33124] C++ frontend should not warn about new a[0] in template context
--- Comment #8 from paolo at gcc dot gnu dot org 2007-09-16 22:54 --- Subject: Bug 33124 Author: paolo Date: Sun Sep 16 22:54:12 2007 New Revision: 128531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128531 Log: /cp 2007-09-16 Paolo Carlini [EMAIL PROTECTED] PR c++/33124 * init.c (build_new): Remove warning for zero-element allocations. /testsuite 2007-09-16 Paolo Carlini [EMAIL PROTECTED] PR c++/33124 * g++.dg/warn/new1.C: Adjust. * g++.dg/torture/str_empty.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/str_empty.C trunk/gcc/testsuite/g++.dg/warn/new1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33124
[Bug c++/33124] C++ frontend should not warn about new a[0] in template context
--- Comment #9 from pcarlini at suse dot de 2007-09-16 22:55 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33124
[Bug inline-asm/33451] New: Collapsing of offsetable memory operands.
Consider the case when a class contains an aggregate member:
struct foo
{
struct bar
{
int one[256];
int two[256];
};
bar my_bar;
};
foo *fooptr;
The members one and two are clearly offsetable memory operands, yet gcc
does not accept them as operands to asm statements.
asm( ... : : o (fooptr-my_bar.two) ) // ERROR memory operand not directly
addressable.
The expected behaviour is to generate code like this:
mov fooptr, %eax
mov 256(%eax), ... // fooptr-my_bar.two
--
Summary: Collapsing of offsetable memory operands.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cschueler at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33451
[Bug web/33057] version-independent url for documentation
--- Comment #3 from gerald at pfeifer dot com 2007-09-17 00:13 --- Change committed to wwwdocs CVS module and life on gcc.gnu.org. http://gcc.gnu.org/onlinedocs/ref it is! -- gerald at pfeifer dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33057
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2007-09-17 00:49 --- The proposed patch to fix PR rtl-optimization/26449... http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01303.html ...eliminates the bootstrap problems with java on powerpc-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug middle-end/33273] [4.3 Regression] FAIL: 27_io/basic_istream/ignore/char/1.cc (test for excess errors)
--- Comment #6 from danglin at gcc dot gnu dot org 2007-09-17 02:13 --- Subject: Bug 33273 Author: danglin Date: Mon Sep 17 02:13:23 2007 New Revision: 128537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128537 Log: PR middle-end/33273 * expr.c (store_expr): Call adjust_address to change mode of dest_mem to BLKmode. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33273
[Bug middle-end/33273] [4.3 Regression] FAIL: 27_io/basic_istream/ignore/char/1.cc (test for excess errors)
--- Comment #7 from danglin at gcc dot gnu dot org 2007-09-17 02:15 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33273
[Bug target/33359] [4.3 Regression] libgcc is miscompiled on SH
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-09-17 02:22 ---
I've looked at the issue for gc-improv branch. I'd like to
add Laurynas to the CC list.
It seems the following back end patch fix the error in #0
on r128224.
--- ORIG/gc-improv/gcc/config/sh/sh.c 2007-09-14 08:56:42.0 +0900
+++ LOCAL/gc-improv/gcc/config/sh/sh.c 2007-09-14 09:41:59.0 +0900
@@ -4480,7 +4480,7 @@ gen_far_branch (struct far_branch *bp)
emit_barrier_after (jump);
emit_label_after (bp-near_label, insn);
JUMP_LABEL (jump) = bp-far_label;
- ok = invert_jump (insn, label, 1);
+ ok = invert_jump (insn, label, 0);
gcc_assert (ok);
/* If we are branching around a jump (rather than a return), prevent
though I get an another error during compiling libiberty/hashtab.c.
A reduced testcase is
unsigned int searches;
unsigned int collisions;
double
htab_collisions (void)
{
if (searches == 0)
return 0.0;
return (double) collisions / (double) searches;
}
which segfaults in final.c:insn_current_reference_address
with a null NEXT_INSN (PREV_INSN (branch)) at -O2.
This problem seems to be generic for the architectures with
delayed branch slots. In the problematic case, the insn
just before the delayed branch is splitted, i.e. insn A in
(insn A P B ...)
(insn B A N (seq [
(jump_insn C A D ... )
(insn D C N ...)
]))
is splitted to insn_1, insn_2, ... and insn_n with try_split.
try_split inserts insn_1, insn_2, ..., insn_n to just after
insn A
(insn A P B ...)
(insn_1A1 A A2)
(insn_2 A2 A1 A3)
...
(insn_n An An-1 B)
(insn B An N (seq [
(jump_insn C A D ... )
(insn D C N ...)
]))
then deletes insn A with delete_insn. Thus the inner jump insn
in insn B has a bad PREV_INSN. It seems that the following
patch fix this issue.
--- ORIG/gc-improv/gcc/emit-rtl.c 2007-09-14 08:56:59.0 +0900
+++ LOCAL/gc-improv/gcc/emit-rtl.c 2007-09-14 13:55:58.0 +0900
@@ -3368,6 +3368,14 @@ try_split (rtx pat, rtx trial, int last)
}
}
+ /* When the AFTER insn is a sequence, fix PREV_INSN of the first insn
+ of that sequence. */
+ if (after)
+{
+ if (NONJUMP_INSN_P (after) GET_CODE (PATTERN (after)) == SEQUENCE)
+ PREV_INSN (XVECEXP (PATTERN (after), 0, 0)) = insn_last;
+}
+
tem = emit_insn_after_setloc (seq, trial, INSN_LOCATOR (trial));
delete_insn (trial);
With these patches, SH is built successfully on r128224.
The latter patch is tested also for i686-pc-linux-gnu on
trunk (revision 128522) with bootstrap and the top level
make -k check with no new regressions.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||laurynas dot biveinis at
||gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33359
[Bug c++/33452] New: native x86_64-pc-mingw32-g++.exe generate wrong asm that x86_64-pc-mingw32-as.exe can not process
I compile a cross compiler for target x86_64-pc-mingw32,
then use this cross compiler to compile a native compiler for
x86_64-pc-mingw32,
then use native compiler to compile cpp code, it generate following error:
--
$ /c/tools/target/bin/x86_64-pc-mingw32-g++.exe -v -Wall hello.cpp
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../gcc/configure --host=x86_64-pc-mingw32
--enable-languages=c,c++ --disable-nls --disable-multilib
--disable-libstdcxx-pch --enable-long-long
--with-gmp=/home/drangon/mingw/target/forgcc
--prefix=/home/drangon/mingw/target
Thread model: win32
gcc version 4.3.0 20070914 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-mtune=generic'
c:/tools/target/bin/../libexec/gcc/x86_64-pc-mingw32/4.3.0/cc1plus.exe
-quiet -v -iprefix
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/ hello.cpp
-quiet -dumpbase hello.cpp -mtune=generic -auxbase hello -Wall
-version -o C:/DOCUME~1/drangon/LOCALS~1/Temp/ccQL.s
ignoring nonexistent directory
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include/c++/4.3.0
ignoring nonexistent directory
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include/c++/4.3.0/x86_64-pc-mingw32
ignoring nonexistent directory
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include/c++/4.3.0/backward
ignoring nonexistent directory
c:/tools/target/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include/c++/4.3.0
ignoring nonexistent directory
c:/tools/target/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include/c++/4.3.0/x86_64-pc-mingw32
ignoring nonexistent directory
c:/tools/target/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include/c++/4.3.0/backward
ignoring nonexistent directory /home/drangon/mingw/target/include
ignoring nonexistent directory /mingw/include64
#include ... search starts here:
#include ... search starts here:
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../include
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/include
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/include-fixed
c:\tools\target\bin\../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../x86_64-pc-mingw32/include
c:/tools/target/lib/gcc/../../include
c:/tools/target/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.3.0/include
c:/tools/target/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.3.0/include-fixed
c:/tools/target/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../x86_64-pc-mingw32/include
End of search list.
GNU C++ (GCC) version 4.3.0 20070914 (experimental) (x86_64-pc-mingw32)
compiled by GNU C version 4.3.0 20070914 (experimental), GMP
version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 952c5c349b801e679ce084d69ae4e018
hello.cpp: In function 'int main(int, char**)':
hello.cpp:9: warning: format '%d' expects type 'int', but argument 2
has type 'long long unsigned int'
hello.cpp:9: warning: format '%d' expects type 'int', but argument 3
has type 'long long unsigned int'
hello.cpp:9: warning: format '%d' expects type 'int', but argument 4
has type 'long long unsigned int'
COLLECT_GCC_OPTIONS='-v' '-Wall' '-mtune=generic'
c:/tools/target/bin/../lib/gcc/x86_64-pc-mingw32/4.3.0/../../../../x86_64-pc-mingw32/bin/as.exe
-o C:/DOCUME~1/drangon/LOCALS~1/Temp/ccwnbaaa.o
C:/DOCUME~1/drangon/LOCALS~1/Temp/ccQL.s
C:/DOCUME~1/drangon/LOCALS~1/Temp/ccQL.s: Assembler messages:
C:/DOCUME~1/drangon/LOCALS~1/Temp/ccQL.s:107: Error: unknown
pseudo-op: `.hidden'
-
the cpp file is very simple :
--
#include stdio.h
int main( int argc, char * argv[] )
{
printf( hello world.\n );
return 0;
}
---
I use the following command to generate asm code from native compiler :
/c/tools/target/bin/x86_64-pc-mingw32-g++.exe -S t2.cpp
.file t2.cpp
.def___main;.scl2; .type 32; .endef
.section .rdata,dr
LC0:
.ascii hello world.\0
.text
.globl _main
.def_main; .scl2; .type 32; .endef
_main:
LFB6:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
subq$32, %rsp
LCFI2:
movl%ecx, 16(%rbp)
movq%rdx, 24(%rbp)
call___main
leaqLC0(%rip), %rcx
call_puts
movl$0, %eax
leave
ret
LFE6:
.section.eh_frame,dr
Lframe1:
.long LECIE1-LSCIE1
LSCIE1:
.long 0x0
.byte 0x1
.def___gxx_personality_v0; .scl2; .type 32; .endef
.ascii zPR\0
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x6
.byte 0x9b
.long _DW.ref.__gxx_personality_v0-.
.byte 0x1b
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Comment #20 from eweddington at cso dot atmel dot com 2007-09-17 02:31 --- Subject: RE: [avr-gcc] Optimization decrease performance of struct assignment. Here's a patch which doesn't mess up the stack pointer update in the epilogue. Hi Rask, Your patch causes a regression. Sort of. I have a small patch that enables Objective-C for the AVR (not that anyone would or should use it), that hasn't been committed yet: --- gcc/config/avr/avr.h.old2007-08-23 15:18:31.015625000 -0600 +++ gcc/config/avr/avr.h2007-08-23 15:19:17.68750 -0600 @@ -53,7 +53,7 @@ extern int avr_mega_p; extern int avr_have_mul_p; extern int avr_asm_only_p; extern int avr_have_movw_lpmx_p; -#ifndef IN_LIBGCC2 +#if !defined(IN_LIBGCC2) !defined(IN_TARGET_LIBS) extern GTY(()) section *progmem_section; #endif Well, your patch causes a new error in configuring libobjc (when using the patch above): checking for thread model used by GCC... single checking for exception model to use... configure: error: unable to detect exception model make[1]: *** [configure-target-libobjc] Error 1 make[1]: Leaving directory `/c/avrdev/gcc/build' make: *** [all] Error 2 Normally, configure detects the exception model as sjlj. The portion of your patch that changes MOVE_MAX in avr.h is fine. The problem seems to be something with your changes in avr.md. Why this is happening, I don't really know. I'm certainly more concerned with optimizing the C compiler than I am in having ObjC build. Thanks, Eric Weddington -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
