[Bug fortran/27633] Fortran accesses char array as integer with transfer
--- Comment #4 from hjl at lucon dot org 2006-05-21 06:58 --- It is the same as PR 27449. *** This bug has been marked as a duplicate of 27449 *** -- hjl at lucon dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27633
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #3 from hjl at lucon dot org 2006-05-21 06:58 --- *** Bug 27633 has been marked as a duplicate of this bug. *** -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #4 from hjl at lucon dot org 2006-05-21 06:59 --- It also happens on Linux/ia64. -- hjl at lucon dot org changed: What|Removed |Added GCC host triplet|hppa64-hp-hpux11.11 | GCC target triplet|STRICT_ALGINED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug fortran/25090] Bad automatic character length
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-21 07:35 --- Subject: Bug 25090 Author: pault Date: Sun May 21 07:35:05 2006 New Revision: 113949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949 Log: 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * interface.c (gfc_extend_assign): Use new code EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/25090 * resolve.c : Remove resolving_index_expr. (entry_parameter): Remove. (gfc_resolve_expr, resolve_charlen, resolve_fl_variable): Remove calls to entry_parameter and references to resolving_index_expr. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/25090 * gfortran.dg/entry_dummy_ref_1.f90: Remove. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associated_target_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 Removed: trunk/gcc/testsuite/gfortran.dg/entry_dummy_ref_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/dependency.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25090
[Bug fortran/25746] Elemental assignment gives wrong result
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-21 07:35 --- Subject: Bug 25746 Author: pault Date: Sun May 21 07:35:05 2006 New Revision: 113949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949 Log: 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * interface.c (gfc_extend_assign): Use new code EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/25090 * resolve.c : Remove resolving_index_expr. (entry_parameter): Remove. (gfc_resolve_expr, resolve_charlen, resolve_fl_variable): Remove calls to entry_parameter and references to resolving_index_expr. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/25090 * gfortran.dg/entry_dummy_ref_1.f90: Remove. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associated_target_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 Removed: trunk/gcc/testsuite/gfortran.dg/entry_dummy_ref_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/dependency.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25746
[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-21 07:35 --- Subject: Bug 19015 Author: pault Date: Sun May 21 07:35:05 2006 New Revision: 113949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949 Log: 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * interface.c (gfc_extend_assign): Use new code EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/25090 * resolve.c : Remove resolving_index_expr. (entry_parameter): Remove. (gfc_resolve_expr, resolve_charlen, resolve_fl_variable): Remove calls to entry_parameter and references to resolving_index_expr. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/25090 * gfortran.dg/entry_dummy_ref_1.f90: Remove. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associated_target_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 Removed: trunk/gcc/testsuite/gfortran.dg/entry_dummy_ref_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/dependency.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
[Bug fortran/27584] ICE on invalid associate(x,(y))
--- Comment #4 from pault at gcc dot gnu dot org 2006-05-21 07:35 --- Subject: Bug 27584 Author: pault Date: Sun May 21 07:35:05 2006 New Revision: 113949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113949 Log: 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * interface.c (gfc_extend_assign): Use new code EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/25090 * resolve.c : Remove resolving_index_expr. (entry_parameter): Remove. (gfc_resolve_expr, resolve_charlen, resolve_fl_variable): Remove calls to entry_parameter and references to resolving_index_expr. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/25090 * gfortran.dg/entry_dummy_ref_1.f90: Remove. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associated_target_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 trunk/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 Removed: trunk/gcc/testsuite/gfortran.dg/entry_dummy_ref_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/dependency.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 08:08 --- Confirmed based on the patch here and the dup bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 08:08:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug c++/27684] GCC doesn't link code, compiled using boost::mpl. Segmentation failed.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-21 08:05 --- This has been fixed already. The problem was in the demangler of ld. This is not a GCC bug so closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27684
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-21 08:21 --- I have just realised that there is a simple fix for this. It is my use of the scalarizer to perform the actual transfer that is the source of the problem. One of you or Bo suggested using memcpy. That is what I will try. My understanding is that adding the memcpy to se-pre or post and having se-expr == NULL, should effect the transfer without generating a scalarizer loop. Would you be prepared to try a patch, in a day or two? Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet||hppa64-hp-hpux11.11 GCC target triplet||STRICT_ALGINED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-21 08:24 --- HJ Would you also be prepared to try a patch, in a day or two? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug c++/27398] [4.0/4.1/4.2 regression] ICE on missing closing parenthesis
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-21 08:39 --- Subject: Bug 27398 Author: reichelt Date: Sun May 21 08:39:14 2006 New Revision: 113950 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113950 Log: PR c++/27398 * decl.c (grokdeclarator): Return error_mark_node instead of NULL_TREE or void_type_node. * g++.dg/template/crash50.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash50.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27398
[Bug c++/27398] [4.0/4.1 regression] ICE on missing closing parenthesis
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-21 08:41 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE on |on missing closing |missing closing parenthesis |parenthesis | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27398
[Bug middle-end/27696] New: [4.2 Regression] g++.dg/other/i386-2.C ICEs on the mainline on x86_64
/home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h: In function 'void _mm_monitor(const void*, unsigned int, unsigned int)':^M /home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h:116: internal compiler error: in copy_to_mode_reg, at explow.c:635^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See URL:http://gcc.gnu.org/bugs.html for instructions.^M FAIL: g++.dg/other/i386-2.C (test for excess errors) Excess errors: /home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h:116: internal compiler error: in copy_to_mode_reg, at explow.c:635 -- Summary: [4.2 Regression] g++.dg/other/i386-2.C ICEs on the mainline on x86_64 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27696
[Bug middle-end/27696] [4.2 Regression] g++.dg/other/i386-2.C ICEs on the mainline on x86_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 08:45 --- Confirmed based on: http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01139.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 08:45:54 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27696
[Bug c/27697] New: incorrect warning about constness of pointer to an array in a const struct
In this snippet of code:
struct foo {
int x[2][10];
};
void f(void)
{
const struct foo bar;
const int (*baz)[10] = bar.x; /* should be ok */
int (*qoox)[10] = bar.x; /* should warn */
bar.x[0][1] = 23; /* error: asignment to const */
(*qoox)[1] = 23;
}
bar is const, so bar.x is (const int *), so an assignment to (const int *)
should be ok, while an assignment to (int *) violates the type constraints (all
according to 6.7.3 in the Standard).
in gcc 4.1.0, the behaviour is reversed: assignment to (int *) goes unnoticed
while assignment to (const int *) issues an incompatible pointer warning.
--
Summary: incorrect warning about constness of pointer to an array
in a const struct
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fischer at td dot mw dot tum dot de
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
[Bug c/27697] incorrect warning about constness of pointer to an array in a const struct
--- Comment #1 from fischer at td dot mw dot tum dot de 2006-05-21 09:31 --- In the function above: bar.x[0][0] = 23; // gcc 4.1 gives error *bar.x[0] = 23; // gcc 4.1 gives NO error both lines do the same -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
[Bug tree-optimization/26622] [4.0/4.1/4.2 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #7 from kazu at gcc dot gnu dot org 2006-05-21 09:39 --- Posted a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01046.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug rtl-optimization/20583] [4.0 regression] ICE in output_operand: invalid expression as operand
--- Comment #11 from kazu at gcc dot gnu dot org 2006-05-21 09:51 --- Unassignining myself. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug tree-optimization/22360] [4.0 Regression] upper_bound_in_type and lower_bound_in_type are buggy
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-21 09:53 --- Unassigning myself. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22360
[Bug fortran/27698] New: subroutine _foo draws unclassifiable statement instead of a useful error.
subroutine _foo end draws the following error: In file bhatt.f:1 subroutine _foo 1 Error: Unclassifiable statement at (1) whereas the compiler would be far more helpful pointing out that _foo is against the Standard (Rule R304: A name should start with a letter). -- Summary: subroutine _foo draws unclassifiable statement instead of a useful error. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug tree-optimization/26678] [4.1/4.2 Regression] GNAT BUG DETECTED when compiling AWS.
--- Comment #17 from laurent at guerby dot net 2006-05-21 10:24 --- This is fixed with: gcc version 4.2.0 20060518 (experimental) gcc version 4.1.1 20060517 (prerelease) -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
[Bug web/27699] New: [bugzilla] CC should be transferred when closing a bug as duplicate
PR 27251 was closed as a duplicate of PR 18058. I was on the CC: list of PR 27251 and had to add myself to the CC: list of PR 18058 manually (as the bug activity will show). -- Summary: [bugzilla] CC should be transferred when closing a bug as duplicate Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27699
[Bug fortran/27698] subroutine _foo draws unclassifiable statement instead of a useful error.
--- Comment #1 from aldot at gcc dot gnu dot org 2006-05-21 11:50 --- Created an attachment (id=11490) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11490action=view) print error invalid form for SUBROUTINE at Not tested. 2006-05-21 Bernhard Fischer [EMAIL PROTECTED] PR fortran/27698 *decl.c (gfc_match_subroutine): Emit error if the name of a subroutine is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug fortran/27613] compile fails with Unclassifiable statement error message
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-21 11:53 --- Subject: Bug 27613 Author: pault Date: Sun May 21 11:53:02 2006 New Revision: 113951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113951 Log: 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. 2006-05-21 Paul Thomas [EMAIL PROTECTED] PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27613
[Bug fortran/27698] subroutine _foo draws unclassifiable statement instead of a useful error.
-- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-05-21 11:53:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 --- Setting Target Milestone to 4.1.1. Ok for trunk and the 4.1 branch? -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Target Milestone|4.1.2 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #15 from aldot at gcc dot gnu dot org 2006-05-21 13:10 --- Subject: Bug 25776 Author: aldot Date: Sun May 21 13:10:37 2006 New Revision: 113952 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113952 Log: ACKed by Jan Hubicka in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776#c9 PR middle-end/25776 * cgraphunit.c (verify_cgraph_node): Typo in error message. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-21 13:49 --- Dale, This looks like a library problem. Jerry committed a change that might have required a completely clean tree to build. I had no trouble with the trunk of two hours ago on FC5/Athlon. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-21 13:59 --- Created an attachment (id=11491) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11491action=view) Patch for this PR and PR27155 This is a belt-and-braces fix that uses memcpy to effect the transfer. I will look for a more efficient solution, which I think will involve a new library function. In the mean time, I believe that the patch will fix your problem. Regtests on FC5/Athlon1700 Could one or, preferably, both of you try out the patch, please? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug libfortran/26346] FAIL: gfortran.dg/secnds.f -O0 execution test
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:02 --- Unless we have some more information about this one, I'd like to close it because it's most likely to be a timeout error than a real problem in the code. Especially if it only fails at -O0, while being a library test :) Please reopen if you have more info! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26346
[Bug libfortran/27046] [mingw32] gfortran print flush in dll
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:03 --- Confirmed. I don't understand why, though. I'll try it harder when I have some leisure time. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 14:03:39 date|| Summary|gfortran print flush in dll |[mingw32] gfortran print ||flush in dll http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug libfortran/27107] Make dependency on io/io.h broken
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:05 --- Confirmed. I think that having a io/io.h file instead of having all prototypes in libgfortran.h is fundamentally a bad idea, especially since things are now spread all around the libgfortran directory. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2006-05-21 14:05:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug libfortran/26540] some gcc-4.1.0/libgfortran/intrinsics/signal.c warning: cast from/to pointer to/from integer of different size on x86-64
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:11 --- Yes, this is confirmed. I'm not sure what is the less dirty way to make the warnings disappear (and not fix the code, which is, as Andrew said, expected not to work well on 64bits platforms). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 14:11:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug fortran/27701] New: Two routines with the same name cause an interna; error in gfortran
The source code: module aha contains subroutine aa write(*,*) 'AA' end subroutine aa subroutine aa write(*,*) 'BB' end subroutine aa end module causes an internal error: Driving: gfortran -v -save-temps double_routine.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i686-pc-cygwin Configured with: ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --enable-languages=c,fortran --disable-bootstrap : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --enable-languages=c,fortran --disable-bootstrap : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../trunk/configure --prefix=/irun --with-mpfr=/usr/local/gmp --with-gmp=/usr/local/gmp --disable-bootstrap --enable-languages=c,fortran --enable-languages=c,fortran --no-create --no-recursion Thread model: single gcc version 4.2.0 20060420 (experimental) /cygdrive/c/arjen/gfortran/bin/../libexec/gcc/i686-pc-cygwin/4.2.0/f951.exe double_routine.f90 -quiet -dumpbase double_routine.f90 -mtune=generic -auxbase double_routine -version -I /cygdrive/c/arjen/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.2.0/finclude -o double_routine.s GNU F95 version 4.2.0 20060420 (experimental) (i686-pc-cygwin) compiled by GNU C version 3.2 20020927 (prerelease). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 double_routine.f90:3: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1153 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Two routines with the same name cause an interna; error in gfortran Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjen dot markus at wldelft dot nl GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug c/27702] New: the trampoline code of nested functions depends on executable stacks
As discussed in this thread:
URL:http://gcc.gnu.org/ml/gcc-help/2005-12/msg00173.html
Many GNU/Linux distributions (such as Debian, Ubuntu and RedHat) are planning
to prohibit executable stacks completely, regardless of the presence of the
executable stack flag. At the moment, GCC produces trampoline code for nested
functions on the stack, so the use of nested functions will disable programs,
thus nested functions won't be usable in reality.
Here is an example of producing trampoline code on the stack:
gcc -O1 -save-temps -c nested_test.c
# 1 nested_test.c
# 1 built-in
# 1 command line
# 1 nested_test.c
void f0(void (*f)());
long f1 (void)
{
long i = 0;
void f2(void)
{
i++;
}
f0(f2);
return i;
}
void f0(void (*f)())
{
(*f)();
}
int main()
{
return f1();
}
As Ian suggested in URL:http://gcc.gnu.org/ml/gcc-help/2005-12/msg00177,
it would work on POSIX systems to put trampoline code on read-write pages
allocated by mmap then switch to read-exec by mprotect before jumping
to the trampoline code.
--
Summary: the trampoline code of nested functions depends on
executable stacks
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: okuji at enbug dot org
GCC build triplet: i586-mandriva-linux-gnu
GCC host triplet: i586-mandriva-linux-gnu
GCC target triplet: i586-mandriva-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27702
[Bug fortran/27703] New: Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character
Unfortunately I have not succeeded in reproducing this error in a small program. The error messages are: /bin/sh ../../libtool --tag=F77 --mode=link gfortran -I../../include -g -O2 -o x01f.exe x01f.o ../../src/libplplotd.la ../../bindings/f77/libplplotf77cd.la ../../bindings/f77/libplplotf77d.la -lm mkdir .libs gfortran -I../../include -g -O2 -o .libs/x01f.exe x01f.o ../../src/.libs/libplplotd.dll.a -L/usr/lib -L/usr/X11R6/lib ../../bindings/f77/.libs/libplplotf77cd.dll.a ../../bindings/f77/.libs/libplplotf77d.dll.a /cygdrive/c/arjen/plplot-5.6.0-cvs/plplot/bindings/f77/.libs/libplplotf77cd.dll.a /cygdrive/c/arjen/plplot-5.6.0-cvs/plplot/src/.libs/libplplotd.dll.a /cygdrive/c/arjen/plplot-5.6.0-cvs/plplot/lib/csa/.libs/libcsirocsa.dll.a /usr/lib/libgd.dll.a /usr/lib/libiconv.dll.a -lXpm -lX11 /usr/lib/libjpeg.dll.a /usr/lib/libfontconfig.dll.a /usr/lib/libexpat.dll.a -lpng12 /usr/lib/libfreetype.dll.a -lz -lgdi32 -L/usr/local/lib /cygdrive/c/arjen/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.1.0/../../../libgfortran.a(transfer.o): In function `*__gfortran_transfer_character': /cygdrive/d/gcc-snap/build/i686-pc-cygwin/libgfortran/../../../gcc-4.1-20050522/libgfortran/io/transfer.c:833: multiple definition of `__gfortran_transfer_character' ../../bindings/f77/.libs/libplplotf77d.dll.a(d44.o):: first defined here /cygdrive/c/arjen/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.1.0/../../../libgfortran.a(transfer.o): In function `*__gfortran_st_write': /cygdrive/d/gcc-snap/build/i686-pc-cygwin/libgfortran/../../../gcc-4.1-20050522/libgfortran/io/transfer.c:1588: multiple definition of `__gfortran_st_write' ../../bindings/f77/.libs/libplplotf77d.dll.a(d36.o):: first defined here /cygdrive/c/arjen/gfortran/bin/../lib/gcc/i686-pc-cygwin/4.1.0/../../../libgfortran.a(transfer.o): In function `*__gfortran_st_write_done': /cygdrive/d/gcc-snap/build/i686-pc-cygwin/libgfortran/../../../gcc-4.1-20050522/libgfortran/io/transfer.c:1598: multiple definition of `__gfortran_st_write_done' ../../bindings/f77/.libs/libplplotf77d.dll.a(d37.o):: first defined here -- Summary: Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjen dot markus at wldelft dot nl GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27703
[Bug rtl-optimization/27671] [4.2 Regression] optimization error on pentium4-Linux with %, regression from gcc-4.1.0
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-21 15:13 --- Subject: Bug 27671 Author: kazu Date: Sun May 21 15:13:36 2006 New Revision: 113955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113955 Log: gcc/ PR rtl-optimization/27671 * simplify-rtx.c (simplify_relational_operation_1): Fix simplifications of (eq/ne (xor x y) y) and (eq/ne (xor x y) x). gcc/testsuite/ PR rtl-optimization/27671 * gcc.c-torture/execute/pr27671-1.c: New. * gcc.dg/pr27671-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr27671-1.c trunk/gcc/testsuite/gcc.dg/pr27671-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27671
[Bug tree-optimization/26622] [4.0/4.1/4.2 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #8 from kazu at gcc dot gnu dot org 2006-05-21 15:16 --- Subject: Bug 26622 Author: kazu Date: Sun May 21 15:16:19 2006 New Revision: 113956 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113956 Log: gcc/ PR tree-optimization/26622. * fold-const.c (fold_ternary) COND_EXPR: Call fold_convert on arg1. gcc/testsuite/ PR tree-optimization/26622. * gcc.c-torture/compile/pr26622.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr26622.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug rtl-optimization/27671] [4.2 Regression] optimization error on pentium4-Linux with %, regression from gcc-4.1.0
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-21 15:17 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27671
[Bug tree-optimization/26622] [4.0/4.1/4.2 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #9 from kazu at gcc dot gnu dot org 2006-05-21 15:17 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug web/27699] [bugzilla] CC should be transferred when closing a bug as duplicate
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 15:53 --- Actually this is done already when closing as a dup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27699
[Bug libfortran/26346] FAIL: gfortran.dg/secnds.f -O0 execution test
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-21 15:57 --- Subject: Re: FAIL: gfortran.dg/secnds.f -O0 execution test I now think that this comment was likely correct. This test can sometimes fail if you have a lot of background tasks running. I found yesterday that the Xserver update on Jan. 29, 2006 introduced a problem with the console login. The server was constantly restarting. I also found another process running continually. I guess it shows I don't use the console much! These problems are now fixed. I have a full 4.2 build running and should know tomorrow if there is still a problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26346
[Bug fortran/27703] Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:01 --- Arjen, There appears to be something strange with your report. The Reported Against field in bugzilla shows 4.2.0. But, the verbose output shows that you are linking against a 4.1.0-20050522 libgfortran. Can you confirm the version of gfortran you have? If you have gfortran 4.1, dated 2005-05-22, you'll need to update. I believe this problem may have been fixed in March of 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27703
[Bug c/27702] the trampoline code of nested functions depends on executable stacks
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 16:01 --- There is a bug in the Redhat's kernel for FC5 that causes the trampoline to fail, someone should report this to them. This is not a bug in GCC but with your distro changing the rules that are always used. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27702
[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:03 --- The problem occurs on i386-*-freebsd -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 16:03:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug middle-end/26622] [4.0/4.1/4.2 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-21 16:09 --- Only fixed on the trunk so reopening as this is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Component|tree-optimization |middle-end Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug middle-end/26622] [4.0/4.1 Regression] ICE in extract_insn, at recog.c:2084
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Known to work|3.4.3 |3.4.3 4.2.0 Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1 Regression] ICE in |in extract_insn, at |extract_insn, at |recog.c:2084|recog.c:2084 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug fortran/27698] subroutine _foo draws unclassifiable statement instead of a useful error.
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-21 16:14 --- Bernhard, Your patch only addresses one aspect of the problem. Consider function _foo entry _bar end function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug c/27697] [4.0/4.1/4.2 Regression] incorrect warning about constness of pointer to an array in a const struct
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:15 --- This is also rejects valid with -pedantic-errors. I don't understand what is correct here so I am not going to confirm it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic, rejects-valid Known to fail||4.0.3 4.1.0 4.2.0 Known to work||4.0.2 Summary|incorrect warning about |[4.0/4.1/4.2 Regression] |constness of pointer to an |incorrect warning about |array in a const struct |constness of pointer to an ||array in a const struct Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-21 16:18 --- This is interesting, I cannot reproduce this with a cross compiler to alphaev68-unknown-linux-gnu from powerpc-darwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet||alpha-linux-gnu GCC host triplet||alpha-linux-gnu GCC target triplet||alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug web/27699] [bugzilla] CC should be transferred when closing a bug as duplicate
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:22 --- Oh, it works the other way in that the CC on the bug which is still opened are transfered over to the bug which is closed now. Anyways this should be reported upstream so closing as will not fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27699
[Bug libfortran/27704] New: Incorrect runtime error on multiple OPEN
The following should not produce a runtime error. OPEN(8, FORM = 'unformatted', STATUS = 'scratch') OPEN(8, FORM = 'unformatted', STATUS = 'scratch') end There may be other combinations of arguments to open that should not error, See the following thread: http://gcc.gnu.org/ml/fortran/2006-05/msg00307.html -- Summary: Incorrect runtime error on multiple OPEN Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27704
[Bug target/27705] New: gcc.dg/sibcall-7.c execution test fails
FAIL: gcc.dg/sibcall-7.c execution test appeared on ia64-hp-hpux11.23 (both ilp32 and lp64) when the test was added on both mainline and 4.1 branch; gcc-testresults shows it also on ia64-linux. I don't know whether this is a target bug (i.e. the test should pass) or a testsuite bug (i.e. it should be skipped on IA64); if the latter, it is a regression. -- Summary: gcc.dg/sibcall-7.c execution test fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27705
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #8 from falk at debian dot org 2006-05-21 16:34 --- (In reply to comment #7) This is interesting, I cannot reproduce this with a cross compiler to alphaev68-unknown-linux-gnu from powerpc-darwin. Hrm :-(. Can anybody try a cross-compiler on i386 with valgrind? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug testsuite/27706] New: gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen fails
FAIL: gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen appeared on HP-UX targets when the test was added. These targets explicitly import external symbols used, so on such targets the test should test for exactly two appearances of strlen instead of one. -- Summary: gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27706
[Bug testsuite/27706] gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 16:36 --- Confirmed. Darwin has the same issue. It was xfailed there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 16:36:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27706
[Bug target/27705] [4.1/4.2 regression] gcc.dg/sibcall-7.c execution test fails
--- Comment #1 from schwab at suse dot de 2006-05-21 16:40 --- It is a testsuite bug. The problem is that on ia64 the call frame is allocated on the register stack, not on the normal stack. Thus the recursive call to recurser_void does not change the stack pointer. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 16:40:45 date|| Summary|gcc.dg/sibcall-7.c execution|[4.1/4.2 regression] |test fails |gcc.dg/sibcall-7.c execution ||test fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27705
[Bug target/27707] New: g++.dg/tree-ssa/ivopts-1.C fails
FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not x\[5\] FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not offset: -4B appeared on mainline on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 when the test was added. -- Summary: g++.dg/tree-ssa/ivopts-1.C fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27707
[Bug tree-optimization/27708] New: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(int\) f_.*with D fails
FAIL: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(int\) f_.*with D appeared on mainline on ia64-hp-hpux11.23 when the test was added. gcc-testresults shows it also failing on several other targets (e.g. ia64-linux, PowerPC, ARM). -- Summary: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(int\) f_.*with D fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27708
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems
--- Comment #8 from hjl at lucon dot org 2006-05-21 16:57 --- The proposed patch works Linux/ia64: http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01188.html The visual inspection shows memcpy is used instead of ld8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug debug/27607] [4.2 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die2.c scan-assembler-not CIE Version
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-05-21 16:58 --- Formerly passed (PASS in revision 113624, FAIL in revision 113643), so a regression. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: |[4.2 Regression] FAIL: |gcc.dg/debug/dwarf2/dwarf- |gcc.dg/debug/dwarf2/dwarf- |die2.c scan-assembler-not |die2.c scan-assembler-not |CIE Version |CIE Version Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27607
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #6 from mark at codesourcery dot com 2006-05-21 17:07 --- Subject: Re: install failure due to unconditional invocation of makeinfo for treelang.texi aldot at gcc dot gnu dot org wrote: --- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 --- Setting Target Milestone to 4.1.1. Ok for trunk and the 4.1 branch? Wouldn't it be better just to modify gcc/Makefile.in to do: ifneq($(BUILD_INFO),) info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo else info: fi Then, in the subdirectory Makefiles we can avoid checking BUILD_INFO at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug c++/27210] [4.2 Regression] ICE on c++ template
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-21 17:24 --- Subject: Bug 27210 Author: mmitchel Date: Sun May 21 17:23:59 2006 New Revision: 113958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113958 Log: PR c++/27210 * cp-tree.h (cp_save_expr): New function. * init.c (build_new): Correct logic for zero-element array warning. Use cp_save_expr. * tree.c (cp_save_expr): New function. PR c++/27210 * g++.dg/warn/new1.C: New test. * g++.dg/template/new5.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/new5.C trunk/gcc/testsuite/g++.dg/warn/new1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27210
[Bug c++/27210] [4.2 Regression] ICE on c++ template
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-21 17:27 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27210
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #9 from hjl at lucon dot org 2006-05-21 17:42 --- I have verified that the proposed patch fixes the C++ run-time problem on Linux/x86, Linux/x86-64 and Linux/ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 --- Wouldn't it be better just to modify gcc/Makefile.in to do: ifneq($(BUILD_INFO),) info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo else info: fi Then, in the subdirectory Makefiles we can avoid checking BUILD_INFO at all. Agree, but i thought that this may be a bit more intrusive than touching the one invalid invocation. Providing an empty info: and perhaps also html: would be the cleanest thing. From the looks, html: may also be needed since gcc/Makefile.in reads: TEXI2HTML = $(MAKEINFO) --html OTOH, html is apparently not in the default install target, so if somebody requests it explicitely, it may be ok to fail noisily. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #8 from mark at codesourcery dot com 2006-05-21 17:58 --- Subject: Re: install failure due to unconditional invocation of makeinfo for treelang.texi aldot at gcc dot gnu dot org wrote: --- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 --- Wouldn't it be better just to modify gcc/Makefile.in to do: ifneq($(BUILD_INFO),) info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo else info: fi Then, in the subdirectory Makefiles we can avoid checking BUILD_INFO at all. Agree, but i thought that this may be a bit more intrusive than touching the one invalid invocation. Your original patch is OK for 4.1 -- but I would like the fix I suggested for 4.2. Also, we don't like to fix a problem on a release branch without also having a fix in mainline. Therefore, would you please test: (a) for 4.1, your original patch (b) for 4.2/mainline, a patch along the lines I suggested above, together with removing checks for BUILD_INFO from */Make-lang.in ? OTOH, html is apparently not in the default install target, so if somebody requests it explicitely, it may be ok to fail noisily. Yes, I think we can avoid this complication for HTML. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-21 18:02 --- I actually got time to test it last night. http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01065.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01065.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #11 from patchapp at dberlin dot org 2006-05-21 18:03 --- Subject: Bug number PR C++/27592 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01065.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug c++/27592] [4.2 Regression] dynamic cast failure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-13 21:38:34 |2006-05-21 18:07:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug fortran/27709] New: Using size of array pointer component as dimension of function result causes gfortran internal error.
The code below causes gfortran to internal error when compiled as follows: gfortran -c Elements.F90 gfortran -c Global_Numbering.F90 In file Global_Numbering.F90:9 end module global_numbering 1 Internal Error at (1): find_array_spec(): Component not found This is similar to bug #18568 but differs in that this bug is only exhibited when the size is used in the dimension statement. Calling size in normal code does not cause the problem. I have compiled the test case from #18568 with the same compiler and no error resulted. The gfortran is compiled from SVN and has the following version string: gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure Thread model: posix gcc version 4.2.0 20060519 (experimental) The code is as follows: module elements implicit none type element_type type(ele_numbering_type), pointer :: numbering end type element_type type ele_numbering_type integer, dimension(:,:), pointer :: number2count end type ele_numbering_type contains function element_local_coords(element) result (coords) type(element_type), intent(in) :: element ! The following line is the problem real, dimension(size(element%numbering%number2count, 1)) :: coords coords=0.0 end function element_local_coords end module elements module global_numbering use elements implicit none end module global_numbering -- Summary: Using size of array pointer component as dimension of function result causes gfortran internal error. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David at ham dot dropbear dot id dot au GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709
[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |hjl at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Summary|[gcc 4.1]: Transpose doesn't|[4.1 only]: Transpose |work on function return |doesn't work on function ||return Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #9 from aldot at gcc dot gnu dot org 2006-05-21 20:11 --- Your original patch is OK for 4.1 -- but I would like the fix I suggested for 4.2. Also, we don't like to fix a problem on a release branch without also having a fix in mainline. Therefore, would you please test: (a) for 4.1, your original patch (b) for 4.2/mainline, a patch along the lines I suggested above, together with removing checks for BUILD_INFO from */Make-lang.in ? I will test test the fix you suggested for 4.2 ASAP, but it may take a couple of days. The fix for 4.1 was only tested on 4.2, but should be the same for 4.1. I can double-check on 4.1 tomorrow and apply it if the fix is identical (else i'll follow up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug tree-optimization/21883] [4.1/4.2 Regression] jump threading causing excessive code duplication
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-21 20:13 --- (In reply to comment #10) Evaluation of Steven's patch should occur after 4.1 is branched. Any progress on this, it has been over 3 months since that was written. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21883
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-05-21 20:14 --- Any news on this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libgomp/26175] [4.2 Regression] In gcc-4.2.0 libgomp/.../powerpc/futex.h SYS_futex undefined
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 20:19 --- Any news on this one? Shouldn't we have better autoconf for libgomp to dect the case where SYS_futex does not exist? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26175
[Bug libstdc++/24692] Atomic builtins for v3
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-05-21 20:21 --- Any news on this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug middle-end/26237] [4.2 Regression] None of the OMP_* trees are documented in c-tree.texi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 20:22 --- Any thoughts on this one? It seems like someone connected with the OpenMP project should document these. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26237
[Bug tree-optimization/26251] [4.2 Regression] code size increase with -Os
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:23 --- Jeff any thoughts about this bug since it was caused by your patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
[Bug c/27702] the trampoline code of nested functions depends on executable stacks
--- Comment #2 from subdino2004 at yahoo dot fr 2006-05-21 20:25 --- (In reply to comment #1) This is not a bug in GCC but with your distro changing the rules that are always used. Why should being unable to use local functions be an acceptable side-effect of prohibiting executable stack if there is known solution ? What would be wrong to provide it as an alternative - if not accepted as the default behaviour ? Or should it become a no-one's fault bug ? Ah, not bug, I mean problematic side-effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27702
[Bug fortran/25850] real kind=16 failures on powerpc-darwin
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:27 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug target/25477] __builtin_sqrtl/__builtin_printf does not work unless including math.h/stdio.h
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:27 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #21 from pcarlini at suse dot de 2006-05-21 20:28 --- Yes, the audit trail doesn't say that in private mail with Loren we agreed that for now we only want to minimally take into account --enable-threads, that is exploit the __GTHREADS macro, consistently with other parts of the library (like the allocators). I'm going to implement that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24692] Atomic builtins for v3
--- Comment #13 from pcarlini at suse dot de 2006-05-21 20:30 --- No news about this one. Frankly, since x86-* would not benefit in any way, I consider the work low priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug c/27702] the trampoline code of nested functions depends on executable stacks
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-21 20:32 --- yes but you should report the bug to the distros that change the rules and let them work out a solution instead of having the FSF GCC fix their bug. Anyways Ada needs trampolines. Also it is harder to use mmap and you have to unmmap them which gets crazy which is why using the stack makes stuff easier to work with. Now people writting good code should not be punished by the case where people writting bad code that can be exploited. The problem here is about trust, if you cannot trust a program, don't run it. Making disucsions for me, is wrong. I should be able to decide if I want to trust a program or not and not the distro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27702
[Bug libstdc++/24692] Atomic builtins for v3
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-21 20:33 --- (In reply to comment #13) No news about this one. Frankly, since x86-* would not benefit in any way, I consider the work low priority. What about x86_64 or even PowerPC64 both of which are becoming more popular than x86. In fact in a few years PPC64 might even supass x86 usage (but only because of the PS3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug libstdc++/24692] Atomic builtins for v3
--- Comment #15 from pcarlini at suse dot de 2006-05-21 20:36 --- (In reply to comment #14) (In reply to comment #13) No news about this one. Frankly, since x86-* would not benefit in any way, I consider the work low priority. What about x86_64 Of course by x86-* I meant to include x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug fortran/24866] internal compiler error
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:37 --- Why is this code invalid? (the keywork ice-on-invalid-code is set) No error is reported with Sun, Intel and g95. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-01-27 20:46:25 |2006-05-21 20:37:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24866
[Bug rtl-optimization/26375] [4.2 Regression] Swing modulo scheduling results in ICE
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-21 20:48 --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00519.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26375
[Bug fortran/20892] dummy procedure can't be generic
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:49
---
Proposed patch (wording from the g95 error message). With that patch, compiling
the testcase is a bit noisy (additional errors after the first error message),
I'll try to find a cleaner solution.
Index: interface.c
===
--- interface.c (revision 113849)
+++ interface.c (working copy)
@@ -217,6 +217,13 @@
gfc_add_generic (sym-attr, sym-name, NULL) == FAILURE)
return MATCH_ERROR;
+ if (sym-attr.dummy)
+ {
+ gfc_error (Dummy procedure '%s' at %C cannot have a
+generic interface, sym-name);
+ return MATCH_ERROR;
+ }
+
current_interface.sym = gfc_new_block = sym;
break;
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords||patch
Last reconfirmed|2005-12-31 19:59:59 |2006-05-21 20:49:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20892
[Bug rtl-optimization/26855] [4.2 Regression] ICE in add_deps_for_def with -fmodulo-sched -maltivec
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-21 20:49 --- Subject: Bug 26855 Author: pinskia Date: Sun May 21 20:48:30 2006 New Revision: 113960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113960 Log: Add forgot changelog: +2006-05-19 Daniel Berlin [EMAIL PROTECTED] +Kenneth Zadeck [EMAIL PROTECTED] + + PR rtl-optimization/26855 + + * df-scan.c (mw_reg_pool, mw_link_pool): New allocation pools for + multiword refs. + (df_scan_alloc): Added code to properly handle multiword hard + registers and add all_blocks parameter. + (df_scan_free_internal, df_insn_refs_delete, df_ref_record): Added + code to properly handle multiword hard registers. + (df_rescan_blocks): Added code to remove deleted blocks from + bitmap. + (df_ref_create_structure, df_ref_record): Added code to properly + handle subregs. + (df_ref_record_1): Changed DF_REF_CLOBBER into DF_REF_MUST_CLOBBER + and set DF_REF_PARTIAL. + (df_defs_record): Changed DF_REF_CLOBBER into DF_REF_MUST_CLOBBER. + (df_uses_record): Added DF_REF_PARTIAL for subreg. + (df_scan_add_problem): Added flags parameter. + (df_ref_create_structure): Changed switching structure. + (df_bb_refs_record): Fixed case where duplicate artificial refs + were created. Changed location of flags. + (df_record_entry_block_defs): Added code to make stack pointer + live in entry block. Refined cases where frame pointer is needed. + Changed location of flags. + (df_record_exit_block_uses, df_insn_refs_record): Changed location of flags. + (df_set_state): Removed function. + (df_grow_reg_info, df_reg_chain_unlink, df_ref_remove, + df_insn_create_insn_record, df_insn_refs_delete, + df_ref_create_structure): Formatting changes. + * df-core.c (df_mvs_dump, df_set_flags, df_clear_flags, + df_delete_basic_block): New function. + (df_init): Changed location of flags. + (df_add_problem): Added flags parameter and the way flags are + processed. + (df_insn_uid_debug, df_ref_debug, debug_df_defno, debug_df_ref, + debug_df_chain): Improved debugging output. + (df_insn_debug, df_insn_uid_debug): Added multiword reg support. + (df_refs_chain_dump): Removed df parameter. + (df_iterative_dataflow): Added consistency check. + (df_prune_to_subcfg): Made public. + (df_analyze_problem): Added blocks_to_init parameter and made + public. + (df_ref_record, df_bb_refs_record, df_mark_reg, +df_record_exit_block_uses): Whitespace changes. + (df_dump): Whitespace changes. + * df.h: Some reordering to remove forward references. + (df_ref_flags.DF_REF_MW_HARDREG, DF_REF_PARTIAL, + DF_REF_MUST_CLOBBER, DF_REF_MAY_CLOBBER): New fields. + (df_ref_flags.DF_REF_CLOBBER): Deleted field. + (dataflow.flags): New field. + (df.flag): Deleted field. + (df_alloc_function): Added additional bitmap parameter. + (df_dependent_problem_function): New type. + (df_problem.changeable_flags): New field. + (df_ref_flags.DF_REF_DIES_AFTER_THIS_USE, DF_SCAN_INITIAL, + DF_SCAN_GLOBAL, DF_SCAN_POST_ALLOC, df_state): Removed. + (df_mw_hardreg): New struct. + (DF_INSN_UID_MWS): New macro. + (df_refs_chain_dump, df_ref_debug, df_chain_dump): Removed df + parameter. + (df_add_problem, df_ru_add_problem, df_rd_add_problem, + df_lr_add_problem, df_ur_add_problem, df_urec_add_problem, + df_ri_add_problem, df_scan_add_problem): Added flags parameter. + (df_set_state): Removed function. + (df_set_flags, df_clear_flags, df_delete_basic_block) New functions. + * df-problems.c (df_chain_dump): Removed df parameter. + (df_ru_alloc, df_rd_alloc, df_lr_alloc, df_ur_alloc, + df_urec_alloc, df_chain_alloc, df_ri_alloc): Added all blocks + parameter. + (df_ru_alloc, df_rd_alloc): Now resets all blocks. + (df_rd_bb_local_compute_process_def, df_ur_bb_local_compute, + df_chain_create_bb, df_create_unused_note, df_ri_bb_compute): + Split DF_REF_CLOBBER into DF_REF_MAY_CLOBBER and + DF_REF_MUST_CLOBBER cases. + (df_ru_bb_local_compute_process_def, + df_rd_bb_local_compute_process_def, df_lr_bb_local_compute, + df_lr_bb_local_compute, df_ur_bb_local_compute, + df_chain_create_bb): Made subreg aware. + (df_ru_bb_local_compute, df_rd_bb_local_compute, + df_lr_bb_local_compute, df_lr_bb_local_compute, + df_chain_create_bb): Cleanup to use proper macros. + (df_ur_local_finalize, df_urec_local_finalize): Removed unnecessary + code to fixup bitvectors. + (df_ri_alloc): Cleared lifetime. + (df_ignore_stack_reg, df_kill_notes, df_set_notes_for_mw, + df_create_unused_note): New function. + (df_ri_bb_compute,
[Bug c++/20103] [4.0/4.1/4.2 regression] ICE in create_tmp_var with C99 style struct initializer
--- Comment #50 from pinskia at gcc dot gnu dot org 2006-05-21 20:51 --- Any news on this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-21 20:53 --- Any news on this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug c++/27648] [4.0/4.1/4.2 Regression] ICE on attribute on pointers in static_cast
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 21:11 --- Janis, could you do a regression hunt on this bug, using the testcase in comment #1? Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27648
[Bug c++/27640] [4.2 Regression] segfault, related to constructor instantiation and virtual base case and templates and new operator
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 21:24 --- Janis, could you regression hunt on this bug? Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27640
[Bug c++/27666] [4.0/4.1/4.2 regression] ICE with volatile in conditional expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 21:26 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-21 21:26:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug fortran/27613] compile fails with Unclassifiable statement error message
--- Comment #7 from patchapp at dberlin dot org 2006-05-21 21:35 --- Subject: Bug number PR27613 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01044.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27613
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #19 from patchapp at dberlin dot org 2006-05-21 21:35 --- Subject: Bug number PR27155 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01055.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
