[Bug fortran/45689] [F2003] Missing transformational intrinsic in the trans_func_f2003 list
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-09-18 15:58 --- (In reply to comment #3) Am I correct to understand that the current situation (i.e. the error message) is a temporary fix for some missing gfc_simplify_*? If the error message you refer to is Error: transformational intrinsic 'cshift' at (1) is not permitted in an initialization expression then yes. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug fortran/45689] CSHIFT and EOSHIFT are not in the trans_func_f2003 list
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 --- They are not, as there, afaik, are no simplifiers yet. Hence, with your patch they will be accepted, but you'd end up with wrong code at the end, as the functions are not properly simplified and thus not constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 34260 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 31346 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 30668 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #58 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 40011 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 21:12 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-07-18 21:13 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-07-18 21:15 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-07-15 21:37 --- (In reply to comment #13) I'm leaving this assigned to Janus because, as OOP master, he knows best the place(s) where the change(s) have to be applied, for better cleanness, bullet-proof-ness, and any-other-reasons-ness. Well, in fact it is not assigned to Janus. I tell you what - I'll unassign myself. I am too tied up with daytime work to contribute over much to gfortran. Reassigning to Janus then ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org AssignedTo|pault at gcc dot gnu dot org|janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/41539] [OOP] Calling function which takes CLASS: Rank comparison does not work
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-07-15 21:39 --- (From update of attachment 20021) Obsolete duplicate. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Attachment #20021|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41539
[Bug fortran/44960] New: non-array used as an array, identified as an external function
Spin-off from PR43179: type t integer :: a end type t type(t) :: foo ! external :: foo ! Syntax error in PRINT print *, foo(1)%a end foo is used as an array although no declared as one; gfortran takes it as an external function, although one can not access components of returned types directly from the function call as it would be possible in C. The latter is picked up if foo is confirmed as EXTERNAL function. Expected: either error-out on component access on function return value or deduce that it can not be function and must be an array - and error out as it is not declared as one. -- Summary: non-array used as an array, identified as an external function Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44960
[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-15 21:57 --- Spin-off: PR44960 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-07-08 16:47 --- Reduced testcase: Type :: t character (len=32) :: txt(2) End Type Type (t) :: tt = t(/ , /)) print *, tt End Notes: * the vatiable 'tt' must be used, if not used only a warning is printed, no ICE * doing the same with INTEGER instead of CHARACTER works * explicitly assigning the txt component instead of using the structure constructor works -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-08 16:47:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-07-08 18:23 --- (In reply to comment #3) Notes: * the vatiable 'tt' must be used, if not used only a warning is printed, no ICE * doing the same with INTEGER instead of CHARACTER works * explicitly assigning the txt component instead of using the structure constructor works * if the string lengths of component and constructor match, then the compilation completes successfully as well I'd hazard the guess that some string length is not properly copied somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-07-08 20:13 --- (In reply to comment #4) I'd hazard the guess that some string length is not properly copied somewhere. Type :: t character (len=X) :: txt(2) End Type Type (t) :: tt = t((/ 12345, 67890 /)) print *, tt End compilation output X=3, 4.5 ok, but no truncation warning123678 X=3, trunkok, but no truncation warning1236 -- wrong X=5, 4.5 ok 1234567890 X=5, trunkok 1234567890 X=7, 4.5 ok 1234567890 -- wrong? X=7, trunkICE In the last case, I'd expect the output 12345 67890 - is 4.5 wrong here? Possibly related functions: resolve.c (resolve_structure_cons) array.c (gfc_resolve_character_array_constructor) decl.c (gfc_set_constant_character_len) Possibly related PR: PR42526 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-06-13 16:05 --- Subject: Bug 31588 Author: dfranke Date: Sun Jun 13 16:05:01 2010 New Revision: 160684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160684 Log: 2010-06-13 Daniel Franke franke.dan...@gmail.com PR fortran/31588 PR fortran/43954 * gfortranspec.c (lang_specific_driver): Removed deprecation warning for -M. * lang.opt: Add options -M, -MM, -MD, -MMD, -MF, -MG, -MP, -MT, -MQ. * lang-specs.h (CPP_FORWARD_OPTIONS): Add -M* options. * cpp.h (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. * cpp.c (gfc_cpp_option): Add deps* members. (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. (gfc_cpp_init_options): Initialize new options. (gfc_cpp_handle_option): Handle new options. (gfc_cpp_post_options): Map new options to libcpp-options. (gfc_cpp_init): Handle deferred -MQ and -MT options. (gfc_cpp_done): If requested, write dependencies to file. * module.c (gfc_dump_module): Add a module filename as target. * scanner.c (open_included_file): New parameter system; add the included file as dependency. (gfc_open_included_file): Add the included file as dependency. (gfc_open_intrinsic_module): Likewise. * invoke.texi: Removed deprecation warning for -M. * gfortran.texi: Removed Makefile-dependencies project. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c trunk/gcc/fortran/cpp.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/gfortranspec.c trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang-specs.h trunk/gcc/fortran/lang.opt trunk/gcc/fortran/module.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 - 4.4 regression, needed for auto-dependencies)
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-06-13 16:05 --- Subject: Bug 43954 Author: dfranke Date: Sun Jun 13 16:05:01 2010 New Revision: 160684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160684 Log: 2010-06-13 Daniel Franke franke.dan...@gmail.com PR fortran/31588 PR fortran/43954 * gfortranspec.c (lang_specific_driver): Removed deprecation warning for -M. * lang.opt: Add options -M, -MM, -MD, -MMD, -MF, -MG, -MP, -MT, -MQ. * lang-specs.h (CPP_FORWARD_OPTIONS): Add -M* options. * cpp.h (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. * cpp.c (gfc_cpp_option): Add deps* members. (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. (gfc_cpp_init_options): Initialize new options. (gfc_cpp_handle_option): Handle new options. (gfc_cpp_post_options): Map new options to libcpp-options. (gfc_cpp_init): Handle deferred -MQ and -MT options. (gfc_cpp_done): If requested, write dependencies to file. * module.c (gfc_dump_module): Add a module filename as target. * scanner.c (open_included_file): New parameter system; add the included file as dependency. (gfc_open_included_file): Add the included file as dependency. (gfc_open_intrinsic_module): Likewise. * invoke.texi: Removed deprecation warning for -M. * gfortran.texi: Removed Makefile-dependencies project. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c trunk/gcc/fortran/cpp.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/gfortranspec.c trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang-specs.h trunk/gcc/fortran/lang.opt trunk/gcc/fortran/module.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug preprocessor/44526] New: libcpp should avoid circular dependencies
Since r160684 gfortran supports generation of Makefile dependencies via libcpp.
In the example below, foo.mod is a target as it is generated from the .f90
file, but also a dependency as it used in the same source file:
$ cat foo.f90
MODULE foo
END MODULE
USE foo
END
$ gfortran-svn -cpp -M foo.f90
foo.o foo.mod: foo.f90 foo.mod
Make complains about (and drops) the circular dependency.
This could be improved if mkdeps.c (deps_add_dep) would verify that there is no
target of the same name and if there is, would drop the dependency. This
assumes that there is no situation where such a circular dependency would be
actually required.
The case that a target is generated with a respective dependency in place does
not happen in Fortran - to USE a module, it must have been seen before, i.e.
the module file must exist.
Suggested patch:
Index: libcpp/mkdeps.c
===
--- libcpp/mkdeps.c (revision 160677)
+++ libcpp/mkdeps.c (working copy)
@@ -256,8 +256,18 @@ deps_add_default_target (struct deps *d,
void
deps_add_dep (struct deps *d, const char *t)
{
+ unsigned int i;
+
t = munge (apply_vpath (d, t)); /* Also makes permanent copy. */
+ /* Avoid circular dependencies. */
+ for (i = 0; i d-ntargets; i++)
+if (strcmp (d-targetv[i], t) == 0)
+ {
+ free ((void *) t);
+ return;
+ }
+
if (d-ndeps == d-deps_size)
{
d-deps_size = d-deps_size * 2 + 8;
--
Summary: libcpp should avoid circular dependencies
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: patch
Severity: enhancement
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-06-13 16:07 --- Fixed in trunk. See PR44526 for a follow-up request for libcpp. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 - 4.4 regression, needed for auto-dependencies)
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-06-13 16:09 --- Makefile dependency generation is now available in trunk (-cpp -MD). See PR44526 for a follow-up request to libcpp. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/44347] SELECT_REAL_KIND: Wrongly accepts non-scalar arguments
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-06-12 11:21 --- Subject: Bug 44347 Author: dfranke Date: Sat Jun 12 11:21:17 2010 New Revision: 160658 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160658 Log: gcc/fortran/: 2010-06-12 Daniel Franke franke.dan...@gmail.com PR fortran/44347 * check.c (gfc_check_selected_real_kind): Verify that the actual arguments are scalar. gcc/testsuite/: 2010-06-12 Daniel Franke franke.dan...@gmail.com PR fortran/44347 * gfortran.dg/selected_real_kind_1.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/selected_real_kind_1.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/check.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44347] SELECT_REAL_KIND: Wrongly accepts non-scalar arguments
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-06-12 11:22 --- Fixed in trunk and 4.5. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44348] ICE in build_function_decl
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-12 14:43 --- This goes off at a tangent, but still related to this PR ... I think this is valid as the RESULT f is in the scope of g only and shadows the FUNCTION f (Lahey accepts it): FUNCTION f() contains FUNCTION g() RESULT(f) END FUNCTION END FUNCTION But what's going on here? FUNCTION f() RESULT(g) contains FUNCTION g() END FUNCTION END FUNCTION $ gfortran-svn pr44348.f90 pr44348.f90: In function 'f': pr44348.f90:4:0: error: aggregate value used where a float was expected Lahey says: 1723-S: SOURCE.F90, line 3, column 12: 'g' already used as a variable name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
[Bug fortran/44348] ICE in build_function_decl
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-12 17:47 --- The patch below fixes the ICE in comment #2, but not the original report. However, it also message-regresses on FAIL: gfortran.dg/derived_function_interface_1.f90 -O (test for errors, line 41) FAIL: gfortran.dg/derived_function_interface_1.f90 -O (test for errors, line 42) FAIL: gfortran.dg/global_references_1.f90 -O (test for excess errors) Index: decl.c === --- decl.c (revision 160638) +++ decl.c (working copy) @@ -863,7 +863,6 @@ get_proc_name (const char *name, gfc_sym this is handled using gsymbols to register unique,globally accessible names. */ if (sym-attr.flavor != 0 - sym-attr.proc != 0 (sym-attr.subroutine || sym-attr.function) sym-attr.if_source != IFSRC_UNKNOWN) gfc_error_now (Procedure '%s' at %C is already defined at %L, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-06-12 21:06 --- Would it be ok to require '-cpp' with '-M' or shall '-M' work without explicit preprocessing enabled? In the latter case, would it be ok to enable preprocessing implicitly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-06-12 21:46 --- (In reply to comment #13) Would it be ok to require '-cpp' with '-M' or shall '-M' work without explicit preprocessing enabled? In the latter case, would it be ok to enable preprocessing implicitly? Passing -M to the driver implies -E - so much for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/44457] Missing ASYNCHRONOUS constraint check
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-10 17:47 --- (In reply to comment #2) Thus, I do not see why one should add another version check. Fine by me. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-10 17:47:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44457
[Bug fortran/44457] Missing ASYNCHRONOUS constraint check
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-10 18:26 --- Subject: Bug 44457 Author: dfranke Date: Thu Jun 10 18:25:56 2010 New Revision: 160567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160567 Log: gcc/fortran/: 2010-06-10 Daniel Franke franke.dan...@gmail.com PR fortran/44457 * interface.c (compare_actual_formal): Reject actual arguments with array subscript passed to ASYNCHRONOUS dummys. gcc/testsuite/: 2010-06-10 Daniel Franke franke.dan...@gmail.com PR fortran/44457 * gfortran.dg/asynchronous_3.f03 Added: trunk/gcc/testsuite/gfortran.dg/asynchronous_3.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44457
[Bug fortran/44457] Missing ASYNCHRONOUS constraint check
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-10 18:26 --- Thus fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44457
[Bug fortran/44491] Diagnostic just shows During initialization instead of a locus
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-10 20:08 --- (In reply to comment #2) This gives a proper locus: And fails the regression test on gfortran.dg/data_array_5.f90 - this turns out to be another variation of PR35849. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491
[Bug fortran/44348] ICE in build_function_decl
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-10 19:09 --- The same ICE is triggered by subroutine s contains SUBROUTINE s END SUBROUTINE end subroutine -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
[Bug fortran/44491] Diagnostic just shows During initialization instead of a locus
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-10 19:43 --- With '-Wall' one also gets: $ gfortran-svn -Wall pr44491.f90 pr44491.f90:1.31: character*2 escape /'1B'x/ 1 Warning: BOZ literal at (1) is bitwise transferred non-integer symbol 'escape' During initialization Error: Incompatible types in DATA statement at (1); attempted conversion of INTEGER(8) to CHARACTER(1) [in the first message, is there a 'to' missing?] -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-10 19:43:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491
[Bug fortran/44491] Diagnostic just shows During initialization instead of a locus
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-10 19:54 --- This gives a proper locus: Index: expr.c === --- expr.c (revision 160567) +++ expr.c (working copy) @@ -3203,7 +3203,7 @@ gfc_check_assign (gfc_expr *lvalue, gfc_ return SUCCESS; gfc_error (Incompatible types in DATA statement at %L; attempted -conversion of %s to %s, lvalue-where, +conversion of %s to %s, rvalue-where, gfc_typename (rvalue-ts), gfc_typename (lvalue-ts)); return FAILURE; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491
[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:41 --- Subject: Bug 44359 Author: dfranke Date: Wed Jun 9 19:40:58 2010 New Revision: 160505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160505 Log: gcc/fortran/: 2010-06-09 Daniel Franke franke.dan...@gmail.com PR fortran/44359 * intrinsic.c (gfc_convert_type_warn): Further improve -Wconversion. gcc/testsuite/: 2010-06-09 Daniel Franke franke.dan...@gmail.com PR fortran/44359 * gfortran.dg/warn_conversion.f90: Removed check for redundant warning. * gfortran.dg/warn_conversion_2.f90: Use non-constant expression to check for warning. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90 trunk/gcc/testsuite/gfortran.dg/warn_conversion_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-09 19:42 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
[Bug fortran/44442] Useless temporary with RESHAPE
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:45 --- I believe this is a dupe of PR33341. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug fortran/44347] SELECT_REAL_KIND: Wrongly accepts non-scalar arguments
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-09 20:11 --- Confirmed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2010-06-09 20:11:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44457] Missing ASYNCHRONOUS constraint check
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-09 21:19 ---
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Index: interface.c
===
--- interface.c (revision 160504)
+++ interface.c (working copy)
@@ -2133,13 +2133,15 @@ compare_actual_formal (gfc_actual_arglis
if ((f-sym-attr.intent == INTENT_OUT
|| f-sym-attr.intent == INTENT_INOUT
- || f-sym-attr.volatile_)
+ || f-sym-attr.volatile_
+ || f-sym-attr.asynchronous)
has_vector_subscript (a-expr))
{
if (where)
- gfc_error (Array-section actual argument with vector subscripts
- at %L is incompatible with INTENT(OUT), INTENT(INOUT)
- or VOLATILE attribute of the dummy argument '%s',
+ gfc_error (Array-section actual argument with vector
+ subscripts at %L is incompatible with INTENT(OUT),
+ INTENT(INOUT), VOLATILE or ASYNCHRONOUS attribute
+ of the dummy argument '%s',
a-expr-where, f-sym-name);
return 0;
}
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44457
[Bug fortran/44347] SELECT_REAL_KIND: Wrongly accepts non-scalar arguments
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-06-09 21:36 --- Subject: Bug 44347 Author: dfranke Date: Wed Jun 9 21:36:33 2010 New Revision: 160506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160506 Log: gcc/fortran/: 2010-06-09 Daniel Franke franke.dan...@gmail.com PR fortran/44347 * check.c (gfc_check_selected_real_kind): Verify that the actual arguments are scalar. gcc/testsuite/: 2010-06-09 Daniel Franke franke.dan...@gmail.com PR fortran/44347 * gfortran.dg/selected_real_kind_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/selected_real_kind_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-01 19:50 --- Haven't checked with the testcase from this PR, but it should be handled by: http://gcc.gnu.org/ml/fortran/2010-05/msg00229.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-01 20:43 --- (In reply to comment #1) http://gcc.gnu.org/ml/fortran/2010-05/msg00229.html With this patch: $ gfortran-svn -Wall pr44359.f90 [no warning] $ gfortran-svn -Wall -fno-range-check pr44359.f90 pr44359.f90:3.34: DATA a / Z'F' /, b / Z'3' / 1 Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) pr44359.f90:3.18: DATA a / Z'F' /, b / Z'3' / 1 Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-01 20:43:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
[Bug fortran/44351] [4.3/4.4/4.5] ICE in gfc_assign_data_value_range
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-01 20:53 --- This was recently fixed. *** This bug has been marked as a duplicate of 24978 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44351
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #38 from dfranke at gcc dot gnu dot org 2010-06-01 20:53 --- *** Bug 44351 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||zeccav at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/44354] incorrect output at run time
--- Comment #21 from dfranke at gcc dot gnu dot org 2010-06-01 21:02 --- (In reply to comment #18) Expected: a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu one could consider a default-enabled warning) b) Reject it for -std=f(95,2003,2008) I'd vote to reject it for any -std=*. This extension just asks for trouble. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org GCC host triplet|x86_64-unknown-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-25 18:10 --- Subject: Bug 34260 Author: dfranke Date: Tue May 25 18:10:01 2010 New Revision: 159838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159838 Log: gcc/fortran/: 2010-05-25 Daniel Franke franke.dan...@gmail.com PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Add check for global procedures with implicit interfaces and assumed-shape or optional dummy arguments. Verify that function return type, kind and string lengths match. gcc/testsuite/: 2010-05-25 Daniel Franke franke.dan...@gmail.com PR fortran/30668 PR fortran/31346 PR fortran/34260 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr40999.f trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-25 18:10 --- Subject: Bug 31346 Author: dfranke Date: Tue May 25 18:10:01 2010 New Revision: 159838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159838 Log: gcc/fortran/: 2010-05-25 Daniel Franke franke.dan...@gmail.com PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Add check for global procedures with implicit interfaces and assumed-shape or optional dummy arguments. Verify that function return type, kind and string lengths match. gcc/testsuite/: 2010-05-25 Daniel Franke franke.dan...@gmail.com PR fortran/30668 PR fortran/31346 PR fortran/34260 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr40999.f trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/30668] -fwhole-file should catch function of wrong type
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-25 18:10 --- Subject: Bug 30668 Author: dfranke Date: Tue May 25 18:10:01 2010 New Revision: 159838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159838 Log: gcc/fortran/: 2010-05-25 Daniel Franke franke.dan...@gmail.com PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Add check for global procedures with implicit interfaces and assumed-shape or optional dummy arguments. Verify that function return type, kind and string lengths match. gcc/testsuite/: 2010-05-25 Daniel Franke franke.dan...@gmail.com PR fortran/30668 PR fortran/31346 PR fortran/34260 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr40999.f trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-25 18:11 --- Commit in #5 catches the OPTIONAL argument if the testcase is compiled with -fwhole-file. However, the warning regarding the inconsistent use of SUB is still missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-05-24 10:44 --- (In reply to comment #12) With -fwhole-file, we get for the short testcase: ../pr36553/pr36553.f90:2.9: print *, f( (/ 0.0, 1.0/) ) 1 Error: The reference to function 'f' at (1) either needs an explicit INTERFACE or the rank is incorrect Argh! How did I miss that? Ok, if the array valued result is removed, it goes again unnoticed: real :: f print *, f( (/ 0.0, 1.0/) ) end function f(x) real, intent(in) :: x(:) ! assumed shape requires explicit interface in caller real :: f f = sum(x) end function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-24 14:03 --- (In reply to comment #13) Should we close this? Yes, this is testcase gfortran.dg/whole_file_2.f90. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-23 15:37 --- Adjusted summary to better describe the problem. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in simplification of|ICE in |spread intrinsic|gfc_conv_array_initializer ||due to incomplete ||simplification of init ||expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996
[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-23 16:16 --- Aren't PR32454 and PR34741 duplicates of this also? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059
[Bug fortran/36271] Add -Wsurprising for pointers arguments with INTENT(IN)?
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-23 18:40 --- (In reply to comment #5) if others feel like me, the PR can be closed as WONTFIX. If I understand it correctly, this is a request to warn about a valid operation. Err, no. WONTFIX, at the least. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-23 19:06 --- Still an issue with gcc version 4.6.0 20100520 (experimental) (GCC) Replaced ice-on-invalid with accepts-invalid keyword. The compiler is fine, the produced binary isn't - there should be no binary. Smaller testcase: real :: f print *, f( (/ 0.0, 1.0/) ) end function f(x) real, intent(in) :: x(:) ! assumed shape requires explicit interface in caller real :: f(size(x)) f = sin(x) ! array valued result requires explicit interface in caller end function What bothers me: how are we supposed to determine if an explicit interface would be required, if the function in questions is in a different compilation unit? Can -fwhole-program/-flto, or whatever else looks at the whole picture, tweaked to do that? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code |accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug fortran/39795] Support round-to-zero in Fortran front-end
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39795
[Bug fortran/40581] Missed optimization in scalar operators on arrays
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-23 19:18 --- (In reply to comment #1) What do you want to do with this, Tobias? This PR is still somewhat sparse on detail of the nature of the problem?! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40581
[Bug fortran/33204] Run-time argument check for procedures (run-time interface checking)
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-23 22:29 --- I think this is a technical dupe of PR27989?! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33204
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-23 22:34 --- *** This bug has been marked as a duplicate of 31346 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-23 22:34 --- *** Bug 36553 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays without explicit interface
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-23 22:35 --- The dupe had accepts-invalid, adding it here. Pushing back from enhancement to normal. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||accepts-invalid Known to fail|4.3.0 4.2.0 4.5.0 |4.3.0 4.2.0 4.5.0 4.6.0 Summary|wrong values for ubound and |wrong values for ubound and |size of deferred shape |size of deferred shape |arrays |arrays without explicit ||interface http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 09:36 --- Confirmed. The problem occurs with allocatable components only, allocatable variables are fine. #0 0x0813d1cd in conformable_arrays (e1=0x8bff710, e2=0x8bc9a30) at /home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:6077 #1 0x0813d7df in resolve_allocate_expr (e=0x8bc9a30, code=0x8bff778) at /home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:6257 #2 0x0813e1c7 in resolve_allocate_deallocate (code=0x8bff778, fcn=0x8964f31 ALLOCATE) at /home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:6510 #3 0x08141647 in resolve_code (code=0x8bff778, ns=0x8bfdeb8) at /home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:8430 #4 0x0814ad70 in resolve_codes (ns=0x8bfdeb8) at /home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:12757 [...] Note: resolve.c (conformable_arrays) and resolve.c (compare_shapes) seem to do the same. Could they be merged? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-20 09:36:07 date|| Summary|ICE on ALLOCATE statement |ICE with ALLOCATABLE ||components and SOURCE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44207
[Bug fortran/35849] wrong line shown in error message for parameter
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-20 14:33 --- A similar example: $ cat conversion.f90 REAL(8), PARAMETER :: h = HUGE(0.0_8) real*4 x data x / h / end $ gfortran-svn -Wall conversion.f90 conversion.f90:1.28: REAL(8), PARAMETER :: h = HUGE(0.0_8) 1 Error: Arithmetic overflow converting REAL(8) to REAL(4) at (1). This check can be disabled with the option -fno-range-check The overflowing conversion occurs in the DATA statement ^^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35849
[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 16:25 --- Patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00242.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-03-28 17:12:36 |2010-05-20 16:25:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38407
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 17:01 --- A proper come-on-and-pick-up testcase would be nice ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 19:19 --- *** Bug 39994 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059
[Bug fortran/39994] Bounds checking (-fcheck=bounds): A = [ constructor ] does not work
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 19:19 --- (In reply to comment #2) I believe that this is a duplicate of PR 31059. Me too. *** This bug has been marked as a duplicate of 31059 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39994
[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 21:49 --- Subject: Bug 38407 Author: dfranke Date: Thu May 20 21:49:07 2010 New Revision: 159641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159641 Log: gcc/fortran/: 2010-05-20 Daniel Franke franke.dan...@gmail.com PR fortran/38407 * lang.opt (Wunused-dummy-argument): New option. * gfortran.h (gfc_option_t): Add warn_unused_dummy_argument. * options.c (gfc_init_options): Disable warn_unused_dummy_argument. (set_Wall): Enable warn_unused_dummy_argument. (gfc_handle_option): Set warn_unused_dummy_argument according to command line. * trans-decl.c (generate_local_decl): Separate warnings about unused variables and unused dummy arguments. * invoke.texi: Documented new option. gcc/testsuite/: 2010-05-20 Daniel Franke franke.dan...@gmail.com PR fortran/38407 * warn_unused_dummy_argument_1.f90: New. * warn_unused_dummy_argument_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_1.f90 trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38407
[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 21:53 --- It would be nice if -Wunused-dummy-argument would be split from -Wunused-variable and also be moved from -Wall to -Wextra to make it consistent with C, where -Wunused-parameter plays this role. Mostly done. We had unused-dummy warnings in -Wall for so long, that I left them there. The -W[no-]unused-dummy-argument option will be available with 4.6.0. No backport as it is not a feature, not a bug. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38407
[Bug fortran/34505] FLOAT/SNGL: Not accepted as actual argument; diagnostics problems
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 11:44 --- Subject: Bug 34505 Author: dfranke Date: Wed May 19 11:43:53 2010 New Revision: 159558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159558 Log: gcc/fortran/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/34505 * intrinsic.h (gfc_check_float): New prototype. (gfc_check_sngl): New prototype. * check.c (gfc_check_float): New. (gfc_check_sngl): New. * intrinsic.c (add_functions): Moved DFLOAT from aliasing DBLE to be a specific for REAL. Added check routines for FLOAT, DFLOAT and SNGL. * intrinsic.texi: Removed individual nodes of FLOAT, DFLOAT and SNGL, added them to the list of specifics of REAL instead. gcc/testsuite/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/34505 * gfortran.dg/dfloat_1.f90: Add warnings for non-default kind arguments; add check for return value kind. * gfortran.dg/float_1.f90: Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dfloat_1.f90 trunk/gcc/testsuite/gfortran.dg/float_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34505
[Bug fortran/34505] FLOAT/SNGL: Not accepted as actual argument; diagnostics problems
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-19 11:46 --- Fixed in trunk. Closing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34505
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-19 12:55 --- Subject: Bug 38404 Author: dfranke Date: Wed May 19 12:55:26 2010 New Revision: 159561 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159561 Log: gcc/fortran/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/38404 * primary.c (match_string_constant): Move start_locus just inside the string. * data.c (create_character_intializer): Clarified truncation warning. gcc/testsuite/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/38404 * gfortran.dg/data_char_1.f90: Updated warning message. * gfortran.dg/data_array_6.f: New. Added: trunk/gcc/testsuite/gfortran.dg/data_array_6.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/data_char_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-19 12:56 --- Fixed in trunk. Closing. Thanks for the report! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/34505] FLOAT/SNGL: Not accepted as actual argument; diagnostics problems
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-19 12:57 --- (In reply to comment #4) Fixed in trunk. Closing Second try. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34505
[Bug fortran/42360] intent(out)-dummy-not-set warning for types depends on order of component initializers
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-19 13:07 --- Subject: Bug 42360 Author: dfranke Date: Wed May 19 13:07:25 2010 New Revision: 159562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159562 Log: gcc/fortran/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/42360 * gfortran.h (gfc_has_default_initializer): New. * expr.c (gfc_has_default_initializer): New. * resolve.c (has_default_initializer): Removed, use gfc_has_default_initializer() instead. Updated all callers. * trans-array.c (has_default_initializer): Removed, use gfc_has_default_initializer() instead. Updated all callers. * trans-decl.c (generate_local_decl): Do not check the first component only to check for initializers, but use gfc_has_default_initializer() instead. gcc/testsuite/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/42360 * gfortran.dg/warn_intent_out_not_set.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_intent_out_not_set.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42360
[Bug fortran/42360] intent(out)-dummy-not-set warning for types depends on order of component initializers
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 13:28 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42360
[Bug fortran/38822] Compile-time simplification of x**(real)
--- Comment #17 from dfranke at gcc dot gnu dot org 2010-05-19 14:43 --- No more ICE, removed keyword. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-19 16:29 --- Not related to types - this is more about namespace cleanup. Reduced testcase: PROGRAM Main USE, INTRINSIC :: iso_c_binding CALL C_F_POINTER(rws, xrws) XXX ! any error will do END PROGRAM Main SUBROUTINE F() END SUBROUTINE F valgrind: ==24940== Invalid read of size 4 ==24940==at 0x8173957: gfc_delete_symtree (symbol.c:2374) ==24940==by 0x4131BD5: (below main) (libc-start.c:226) ==24940== Address 0x4308fc8 is 0 bytes inside a block of size 1,692 free'd ==24940==at 0x4024B3A: free (vg_replace_malloc.c:366) ==24940==by 0x812A3F5: gfc_free (misc.c:51) ==24940==by 0x4131BD5: (below main) (libc-start.c:226) gdb: Program received signal SIGSEGV, Segmentation fault. 0x081739b2 in gfc_find_symtree (st=0x2e1, name=0xb7eece00 shape) at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2393 2393 c = strcmp (name, st-name); (gdb) bt #0 0x081739b2 in gfc_find_symtree (st=0x2e1, name=0xb7eece00 shape) at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2393 #1 0x08173969 in gfc_delete_symtree (root=0x8c54760, name=0xb7eece00 shape) at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2374 #2 0x08174473 in gfc_undo_symbols () at /home/daniel/svn/gcc-svn/gcc/fortran/symbol.c:2845 #3 0x081385ff in decode_statement () at /home/daniel/svn/gcc-svn/gcc/fortran/parse.c:271 #4 0x0813a0e9 in next_free () at /home/daniel/svn/gcc-svn/gcc/fortran/parse.c:722 #5 0x0813a4d2 in next_statement () at /home/daniel/svn/gcc-svn/gcc/fortran/parse.c:907 #6 0x0813e6a6 in gfc_parse_file () at /home/daniel/svn/gcc-svn/gcc/fortran/parse.c:4220 #7 0x0817cbba in gfc_be_parse_file (set_yydebug=0) at /home/daniel/svn/gcc-svn/gcc/fortran/f95-lang.c:239 #8 0x084cfe1b in compile_file () at /home/daniel/svn/gcc-svn/gcc/toplev.c:1049 #9 0x084d1ed8 in do_compile () at /home/daniel/svn/gcc-svn/gcc/toplev.c:2393 #10 0x084d1f9e in toplev_main (argc=2, argv=0xb3c4) at /home/daniel/svn/gcc-svn/gcc/toplev.c:2435 #11 0x0820961b in main (argc=2, argv=0xb3c4) at /home/daniel/svn/gcc-svn/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.2 4.3.3 4.3.4 4.4.0 |4.3.4 4.4.0 4.5.1 4.6.0 Summary|ICE-on-invalid with |ICE-on-invalid with |ISO_C_BINDING and TYPEs |ISO_C_BINDING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/44055] Warn (-Wconversion*) when converting single to double precision
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-19 16:36 --- Subject: Bug 44055 Author: dfranke Date: Wed May 19 16:35:34 2010 New Revision: 159586 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159586 Log: gcc/fortran/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/44055 * lang.opt (Wconversion-extra): New option. * gfortran.h (gfc_option_t): Add warn_conversion_extra. * options.c (gfc_init_options): Disable -Wconversion-extra by default. (set_Wall): Enable -Wconversion. (gfc_handle_option): Set warn_conversion_extra. * intrinsic.c (gfc_convert_type_warn): Ignore kind conditions introduced for -Wconversion if -Wconversion-extra is present. * invoke.texi: Add -Wconversion to -Wall; document new behaviour of -Wconversion; document -Wconversion-extra. gcc/testsuite/: 2010-05-19 Daniel Franke franke.dan...@gmail.com PR fortran/44055 * gfortran.dg/c_sizeof_2.f90: Add -Wno-conversion to dg-options; Fixed scope of C_SIZEOF. * gfortran.dg/warn_conversion_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_conversion_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_sizeof_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44055
[Bug fortran/38849] ICE in fold_convert with C_F_POINTER and C binding
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-19 16:57 --- $ gfortran-4.5 pr38849.f90 pr38849.f90: In function 'MAIN__': pr38849.f90:9:0: internal compiler error: in gimplify_expr, at gimplify.c:7346 $ gfortran-svn pr38849.f90 gimplification failed: chararr addr_expr 0xb77a43b8 type pointer_type 0xb77a3c00 type function_type 0xb77a3ba0 type void_type 0xb7729780 void QI size integer_cst 0xb77190f0 constant 8 unit size integer_cst 0xb7719108 constant 1 align 8 symtab 0 alias set -1 canonical type 0xb77a3ba0 arg-types tree_list 0xb779ec60 value reference_type 0xb77a3b40 chain tree_list 0xb779ec78 value integer_type 0xb77292a0 integer(kind=4) chain tree_list 0xb779ec90 value void_type 0xb7729780 void pointer_to_this pointer_type 0xb77a3c00 unsigned SI size integer_cst 0xb7719240 constant 32 unit size integer_cst 0xb7719078 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb77a3c00 constant arg 0 function_decl 0xb77a2c00 chararr type function_type 0xb77a3ba0 public external QI file pr38849.f90 line 5 col 0 align 8 chain function_decl 0xb77a2b00 MAIN__ type function_type 0xb774d060 used static QI file pr38849.f90 line 2 col 0 align 8 initial block 0xb7727104 result result_decl 0xb7722348 D.1499 (mem:QI (symbol_ref:SI (MAIN__) [flags 0x3] function_decl 0xb77a2b00 MAIN__) [0 S1 A8]) struct-function 0xb772239c chain function_decl 0xb77a2a80 _gfortran_st_set_nml_var_dim pr38849.f90: In function 'MAIN__': pr38849.f90:9:0: internal compiler error: gimplification failed $ gfortran-svn -v gcc version 4.6.0 20100518 (experimental) (GCC) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Known to fail|4.3.2 4.4.0 |4.3.2 4.4.0 4.5.1 4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38849
[Bug fortran/44055] Warn (-Wconversion*) when converting single to double precision
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-19 17:34 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44055
[Bug fortran/30939] Run-time check if dummy array sizes is larger than actual array size
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 17:53 --- (In reply to comment #2) I dedicate it to the run time test. Test: Place program and subroutine in different files, compile and run them. NAG f95 -C=all shows then: Same as PR27989. *** This bug has been marked as a duplicate of 27989 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30939
[Bug fortran/27989] -fbounds-check should check for too small arrays on subroutine calls
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 17:53 --- *** Bug 30939 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 --- If print *, (foo()) is changed to print *, foo() one gets: $ gfortran-svn pr41859.f90 pr41859.f90:17.19: print *, foo() ! -- ICE here! 1 Error: Data transfer element at (1) cannot have POINTER components Same for the second problem: $ gfortran-svn pr41859-c1.f90 pr41859-c1.f90:37.19: print *, foo() ! 1 Error: Data transfer element at (1) cannot have PRIVATE components -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 21:17:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) print *exp
$2 = {expr_type = EXPR_OP, ts = {type = BT_DERIVED, kind = 0, u = {derived =
0x8bc7ad8, cl = 0x8bc7ad8}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN},
rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where = {nextc = 0x8bfa9ec,
lb = 0x8bfa9b0}, inline_noncopying_intrinsic = 0, is_boz = 0, is_snan = 0,
error = 0,
user_operator = 0, representation = {length = 0, string = 0x0}, value =
{logical = 27, iokind = 27, integer = {{_mp_alloc = 27, _mp_size = 0, _mp_d =
0x8bb1450}}, real = {{
_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp = 146478160, _mpfr_d =
0x0}}, complex = {{re = {{_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp =
146478160, _mpfr_d = 0x0}}, im = {
{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0, op
= {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}, function
= {actual = 0x1b,
name = 0x0, isym = 0x8bb1450, esym = 0x0}, compcall = {actual = 0x1b,
name = 0x0, base_object = 0x8bb1450, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {
length = 27, string = 0x0}, constructor = 0x1b}}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p)! '()' are significant
end
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) p exp-expr_type
$11 = EXPR_OP
(gdb) p exp-ts.u.derived-name
$12 = 0xb7f47a08 ptype
(gdb) p exp-value.op
$13 = {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}
(gdb) p exp-value.op.op1-expr_type
$14 = EXPR_VARIABLE
(gdb) p exp-value.op.op1-ts.u.derived-name
$15 = 0xb7f47a08 ptype
No idea how to fix this, adding the obvious check and workaround for EXPR_OP
feels wrong. More likely, EXPR_OP should never have been passed down here?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/42851] ICE (segfault) at gfc_trans_pointer_assignment for subpointer
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 22:09 --- Reduced testcase: type t real :: a(3) end type t contains function func(x) type(t), target :: x(:) real, dimension(:), pointer :: func func = x%a(1) end function func end -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Known to fail||4.4.3 4.5.1 4.6.0 Priority|P5 |P3 Summary|[4.3/4.4/4.5] ICE (segfault)|ICE (segfault) at |at |gfc_trans_pointer_assignment |gfc_trans_pointer_assignment|for subpointer |for subpointer | Target Milestone|4.3.5 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
[Bug fortran/42851] ICE (segfault) at gfc_trans_pointer_assignment for subpointer
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 22:22 --- Roughly the same testcase, same backtrace. *** This bug has been marked as a duplicate of 34640 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-18 22:22 --- *** Bug 42851 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug fortran/38471] ICE with subreference pointer assignment
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-18 22:26 --- As commented multiple times in PR34640, given the similarity of the testcase, the identical backtrace and the same assignee ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38471] ICE with subreference pointer assignment
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-18 22:28 --- (In reply to comment #11) As commented multiple times in PR34640, given the similarity of the testcase, the identical backtrace and the same assignee ... *** This bug has been marked as a duplicate of 34640 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-18 22:28 --- *** Bug 38471 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-18 22:30 --- The dupes PR38471 and PR42851 have more testcases, the former an equally lengthy discussion as this PR. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-18 22:36 --- (In reply to comment #17) Fixed on the trunk (4.6). Planned to be committed also to GCC 4.5.1. Patch was applied to trunk about 6 weeks ago - how are the backporting plans? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-18 22:38 --- Paul, is there anything left to do here or can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 22:44 --- (In reply to comment #2) OK for trunk with the usual embellishments of ChangeLogs and testcase? Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that EXPR_VARIABLE is enough. Paul, any plans to wrap this up? :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug fortran/44177] gfortran internal data assignment error cause found
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-17 21:10 --- The PR(In reply to comment #3) I think the ICE has been fixed by the recent constructor work by Daniel. That was PR24978. Given that this PR was opened against 4.1 in 2005 and a simple workaround exists (fix your code, i.e. eliminate all double initializations), I don't see much reason for backport. Further, the constructor work is a serious change, I wouldn't want to backport that for so little. Suggest to close as dupe of PR24978. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44177
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-17 22:23 --- (In reply to comment #4) We have complete control of whether to print the negative sign with -fno-sign-zero. I am tempted to say this is a no-never-mind situation. Using the testcase shown in comment #3: $ gfortran-svn pr44156-c3.f90 -fno-sign-zero ./a.out 0.000 0.000 0.000 $ gfortran-svn pr44156-c3.f90 -fsign-zero ./a.out 0.000 0.000 -0.000 The flag does work for the third value, i.e. the line real, parameter :: e = a(1) * b(1) but has no say for the others. Out of curiosity, what do other compilers do? I, right now, don't have any to test with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-17 23:49 --- (In reply to comment #6) I already explained what dot_product is doing in comment #2. dot_product(a,b) is equivalent to s = 0 do n = 1, m s = s + a(n) * b(n) end do (return s) For Thomas' code, you end up with 0 + (-0), which is 0 (which is what IEEE 754 explicitly says in Sec 8.3). Thanks for the clarification. Finally also found the c.l.f thread (where, btw, Tobias answers my question on what other compilers do): http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a693c3dd5f725e77 After reading it, I'd agree that this is probably a non-issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-16 20:01 --- Subject: Bug 35779 Author: dfranke Date: Sun May 16 20:01:06 2010 New Revision: 159465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159465 Log: gcc/fortran/: 2010-05-16 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * array.c (match_array_list): Revert functional change of 2010-05-13. gcc/fortran/: 2010-05-16 Daniel Franke franke.dan...@gmail.com PR fortran/35779 * gfortran.dg/initialization_25.f90: Commented testcase. * gfortran.dg/initialization_26.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_26.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_25.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
