| Summary: | f951: internal compiler error: Segmentation fault | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Joost VandeVondele <Joost.VandeVondele> |
| Component: | fortran | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bdavis, janus, Joost.VandeVondele, jvdelisle2, kimwooyoung, mikael, zeccav |
| Priority: | P3 | Keywords: | error-recovery, ice-on-invalid-code |
| Version: | 4.9.0 | ||
| Target Milestone: | 4.8.5 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2014-12-06 00:00:00 | |
| Attachments: |
Invalid locus when an interface function is undefined
altered patch for the regressions reported in comment 9 altered patch for the regressions reported in comment 11 cleanup if a declaration type spec is erroneous cleanup if a declaration type spec is erroneous Cleaned patch |
||
I can not reproduce the ICE, but I see the corrupted error message and several valgrind errors.
Reduced test case:
MODULE atomic_kind_types
PUBLIC :: atomic_kind_type
CONTAINS
INTEGER FUNCTION is_hydrogen(atomic_kind)
TYPE(atomic_kind_type), pointer :: atomic_kind
END FUNCTION
END MODULE
Is the reduced test case valid code ? Should it compile cleanly or should it provide a warning or error ? With the test in comment 1, I get on x86_64-apple-darwin13: TYPE(atomic_kind_type), pointer :: atomic_kind 1 Error: Derived type 'atomic_kind_type' at (1) is being used before it is defined ,:0: Included at _gfortran_dot_product:4096: Included at __convert_h1_i16:4096: Included at __builtin_frexpf:4096: Included at __atomic_fetch_and_16:4096: Included at __builtin_ia32_packssdw:4096: Included at __builtin_ia32_cvtsi2sd:4096: Included at __builtin_ia32_monitor:4096: Included at :4096: \U42C27000\x01/ f951: internal compiler error: Segmentation fault: 11 f951: internal compiler error: Abort trap: 6 gfc: internal compiler error: Abort trap: 6 (program f951) Abort Backtrace is
Program received signal SIGSEGV, Segmentation fault.
error_print(const char *, const char *, typedef __va_list_tag __va_list_tag *) (type=<optimized out>, format0=<optimized out>, argp=<optimized out>)
at ../../work/gcc/fortran/error.c:173
173 while (*p)
(gdb) bt
#0 error_print(const char *, const char *, typedef __va_list_tag __va_list_tag *) (type=<optimized out>, format0=<optimized out>,
argp=<optimized out>) at ../../work/gcc/fortran/error.c:173
#1 0x000000010002fa4e in gfc_error (gmsgid=<optimized out>) at ../../work/gcc/fortran/error.c:1003
#2 0x000000010003827c in check_interface0 (p=0x141f05ad0, interface_name=0x7fff5fbff060 "generic interface 'atomic_kind_type'")
at ../../work/gcc/fortran/interface.c:1568
#3 0x000000010003b243 in check_sym_interfaces (sym=0x25) at ../../work/gcc/fortran/interface.c:1680
#4 0x00000001000a98dc in do_traverse_symtree (st=<optimized out>, st_func=<optimized out>, sym_func=<optimized out>)
at ../../work/gcc/fortran/symbol.c:3575
#5 0x000000010003c01c in gfc_check_interfaces (ns=0x143020c00) at ../../work/gcc/fortran/interface.c:1790
#6 0x0000000100094071 in resolve_types (ns=<optimized out>) at ../../work/gcc/fortran/resolve.c:14589
#7 0x000000010008f9eb in gfc_resolve (ns=<optimized out>) at ../../work/gcc/fortran/resolve.c:14670
#8 0x000000010007a0a1 in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4672
#9 0x00000001000bc7f6 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:188
#10 0x000000010084c924 in compile_file () at ../../work/gcc/toplev.c:547
#11 0x000000010084ebe9 in toplev_main (argc=2, argv=0x7fff5fbff4d0) at ../../work/gcc/toplev.c:1887
confirmed for trunk, backtrace now: f951: internal compiler error: Segmentation fault 0xb364df crash_signal ../../gcc/gcc/toplev.c:358 0x658af9 gfc_sym_get_dummy_args(gfc_symbol*) ../../gcc/gcc/fortran/symbol.c:4659 0x632130 resolve_fl_procedure ../../gcc/gcc/fortran/resolve.c:11189 0x632130 resolve_symbol ../../gcc/gcc/fortran/resolve.c:13568 0x6511e3 do_traverse_symtree ../../gcc/gcc/fortran/symbol.c:3641 0x63c61f resolve_types ../../gcc/gcc/fortran/resolve.c:14781 0x6304a3 gfc_resolve ../../gcc/gcc/fortran/resolve.c:14882 0x6304a3 gfc_resolve(gfc_namespace*) ../../gcc/gcc/fortran/resolve.c:14870 0x62580a gfc_parse_file() ../../gcc/gcc/fortran/parse.c:5080 0x6652e5 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:222 Please submit a full bug report, Created attachment 35171 [details] Invalid locus when an interface function is undefined The attached patch has various prerequisites and can be applied only manually! A complete list of the prerequisites (patches) for gcc-4.8.4 can be found at: http://users.otenet.gr/~drikosev/downloads/pc-2015-03-28.tar.xz Hi, The reduced test case which has been posted by janus (comment 1) crashes also 4.8.4 and gcc 5.0 (the latter was copied from trunc a few days ago). The backtrace I get agrees with that of Dominique's (comment 4). The problem is likely in function "check_interface0"; the locus of "p->sym" is invalid when gfc_error is called: gfc_error ("Procedure '%s' in %s at %L is neither function nor " "subroutine", p->sym->name, interface_name, &p->sym->declared_at); Likely, the reason is that there is a symbol only in the access statement but the expected function/subroutine hasn't been defined. Perhaps, one can avoid the segmentation fault with an addition argument in function "check_interface0". The argument will be not null only if called by function "check_sym_interfaces"; in which case it will be the symbol that appears in the access-stmt. I'm not really if we can reproduce the error for intrinsic assignment operators but the solution could be similar. Provided that such a patch will be implemented, the second error message for the example at comment 1 would look like: pr59016.f90:2.30: PUBLIC :: atomic_kind_type 1 Error: undefined function/subroutine for generic interface 'atomic_kind_type' at (1) ----------------------------------------------------------------------- PS: please also note that I've not run the regression tests!
When gfortran reports the error, it expects that the name 'atomic_kind_type' is likely a procedure or function; but the syntax of the access-stmt is:
access-stmt ::= access-spec [ [ :: ] access-id-list ]
access-id ::= use-name | generic-spec
access-spec::=
Each use-name shall be the name of a named variable, procedure, derived type, named constant, or namelist group.
Perhaps, a more accurate error message could be:
PUBLIC :: atomic_kind_type
1
Error: Undefined use-name 'atomic_kind_type' in access statement at (1)
I have tested on trunk (5.0) the following variant
--- ../_clean/gcc/fortran/interface.c 2015-03-25 14:07:04.000000000 +0100
+++ gcc/fortran/interface.c 2015-03-30 10:05:08.000000000 +0200
@@ -1558,7 +1569,7 @@ next:
something goes wrong. */
static int
-check_interface0 (gfc_interface *p, const char *interface_name)
+check_interface0 (gfc_interface *p, const char *interface_name, gfc_symbol *origin)
{
gfc_interface *psave, *q, *qlast;
@@ -1571,7 +1582,16 @@ check_interface0 (gfc_interface *p, cons
|| !p->sym->attr.if_source)
&& p->sym->attr.flavor != FL_DERIVED)
{
- if (p->sym->attr.external)
+ if (origin)
+ {
+ /* since program crashes, print access statement info or just the name; then exit! */
+ if (origin->declared_at.lb->file)
+ gfc_error ("undefined function/subroutine for %s at %L ",
+ interface_name, &origin->declared_at);
+ else
+ gfc_error ("undefined function/subroutine for %s ",interface_name);
+ }
+ else if (p->sym->attr.external)
gfc_error ("Procedure %qs in %s at %L has no explicit interface",
p->sym->name, interface_name, &p->sym->declared_at);
else
@@ -1689,7 +1709,7 @@ check_sym_interfaces (gfc_symbol *sym)
if (sym->generic != NULL)
{
sprintf (interface_name, "generic interface '%s'", sym->name);
- if (check_interface0 (sym->generic, interface_name))
+ if (check_interface0 (sym->generic, interface_name, sym))
return;
for (p = sym->generic; p; p = p->next)
@@ -1721,7 +1741,7 @@ check_uop_interfaces (gfc_user_op *uop)
gfc_namespace *ns;
sprintf (interface_name, "operator interface '%s'", uop->name);
- if (check_interface0 (uop->op, interface_name))
+ if (check_interface0 (uop->op, interface_name, NULL))
return;
for (ns = gfc_current_ns; ns; ns = ns->parent)
@@ -1814,7 +1834,7 @@ gfc_check_interfaces (gfc_namespace *ns)
sprintf (interface_name, "intrinsic '%s' operator",
gfc_op2string ((gfc_intrinsic_op) i));
- if (check_interface0 (ns->op[i], interface_name))
+ if (check_interface0 (ns->op[i], interface_name, NULL))
continue;
if (ns->op[i])
It fixes this PR and at least pr56674, pr58813, pr59024, and pr65469. However it causes the following regressions:
FAIL: gfortran.dg/constructor_9.f90 -O (test for errors, line 13)
FAIL: gfortran.dg/constructor_9.f90 -O (test for excess errors)
FAIL: gfortran.dg/generic_14.f90 -O (test for errors, line 90)
FAIL: gfortran.dg/generic_14.f90 -O (test for errors, line 99)
FAIL: gfortran.dg/generic_14.f90 -O (test for excess errors)
FAIL: gfortran.dg/keyword_symbol_1.f90 -O (test for errors, line 20)
FAIL: gfortran.dg/keyword_symbol_1.f90 -O (test for excess errors)
FAIL: gfortran.dg/proc_decl_3.f90 -O (test for errors, line 37)
FAIL: gfortran.dg/proc_decl_3.f90 -O (test for errors, line 38)
FAIL: gfortran.dg/proc_decl_3.f90 -O (test for errors, line 39)
FAIL: gfortran.dg/proc_decl_3.f90 -O (test for excess errors)
Created attachment 35226 [details] altered patch for the regressions reported in comment 9 Hi Dominiq, In a slightly altered patched, I've added a precondition which examines first the locus of the current symbol and finally the error reported seems to comply with the testsuites. I've run the 4 tests one by one with the debugger; I don't know what is exactly the meaning of the phrase "(test for excess errors)" or why each test appears twice in your list. If I miss any important details please tell me. Regards, Ev. Drikos > In a slightly altered patched, I've added a precondition which examines
> first the locus of the current symbol and finally the error reported seems
> to comply with the testsuites.
Indeed, however the new patch does not prevent the ICEs.
AFAICT the basic problem is not with p->sym->declared_at.lb, but with p->sym->name. I have tried to check for p->sym->name==0 which happen sometime, but not always in a seemingly random way.
When p->sym->name!=0 and an ICE, p->sym->name seems malformed. So I suspect a bug upstream where the pointer p->sym->name is not reset to NULL.
BTW your patches do not follow the gnu coding style.
*** Bug 65469 has been marked as a duplicate of this bug. *** Hi Dominiq, The new patch (gcc-4.8.4) worked as the older one but since the locus is corrupted I'm not surprised that a test case you tried failed. Could you post it here please? The corrupted locus is the reason that the patch 65469, submitted by Janus, doesn't work also; the "p->sym->name" sometimes is not null but it points to an invalid location and so one cannot use it in a comparison: if (p->sym->name != NULL ) //segmentation fault! Since the locus is corrupted, in my first patch I avoided to examine it whenever we are about to print an error and the referenced locus was available; which obviously invalidated some test cases in comment 9. To reset the name to null, one needs to figure out where the symbol is created (or assigned to p) which is something I don't know at the moment. With regard to the coding style, I'd like to ask for some indexes (e.g. gnu guideline or something like that). Regards, Ev. Drikos Indeed, the new patch in comment 10 does not prevent the ICEs with the the first example bug.f90 (in Description before comment 1). Created attachment 35230 [details] altered patch for the regressions reported in comment 11 Hi, As it seems the problem with the program bug.f90 is that the generic attribute is set in a symbol as the parser tries to match a declaration type specification; but finally, the statement isn't matched as such and the generic attribute wasn't cleared. So, the attached patch makes the cleanup, without causing the regressions listed in comment 9. The question here is if gfortran had to print an error message for this program: module types public :: undefined end module types write (*,*) "undefined types!" end --------------------------------------------------------------------------- PS: I've not checked out the source code from a repo, so the attached patch is just the output of the diff command (not svn diff). > As it seems the problem with the program bug.f90 is that the generic > attribute is set in a symbol as the parser tries to match a declaration > type specification; but finally, the statement isn't matched as such > and the generic attribute wasn't cleared. > > So, the attached patch makes the cleanup, without causing the regressions > listed in comment 9. IMO the patch addresses the root of the problem and prevents the ICEs in the PRs listed in comment 9. However it causes 3000+ failures in the test suite, so the filter you apply is not narrow enough. > The question here is if gfortran had to print an error message for > this program: > > module types > public :: undefined > end module types > write (*,*) "undefined types!" > end Why should it without "implicit none"? Your patches do not follow the GNU coding standards: http://www.gnu.org/prep/standards/ The last patch should look as --- ../_clean/gcc/fortran/decl.c 2015-03-25 14:07:04.000000000 +0100 +++ gcc/fortran/decl.c 2015-04-05 13:02:38.000000000 +0200 @@ -4427,6 +4427,31 @@ ok: gfc_free_data_all (gfc_current_ns); cleanup: + //<pr59016> in gfc_match_data_decl; cleanup the garbages + gfc_symbol *csym = NULL; + if (current_ts.u.derived && current_ts.u.derived->name) + { + char iname[129]; + iname[128] = 0; + for (int i = 0; i < 128; i++) + { + iname[i] = current_ts.u.derived->name[i]; + if (current_ts.u.derived->name[i] == 0) + break; + } + iname[0] = TOLOWER(iname[0]); + for (int i = 0; i < 4; i++) + { + gfc_find_symbol (iname, NULL, i, &csym) ; + if (csym && csym->generic + && (csym->generic->sym == current_ts.u.derived)) + { + csym->generic = NULL; + break; + } + } + } + //</pr59016> gfc_free_array_spec (current_as); current_as = NULL; return m; (note that I may have done some errors myself). In addition you should comment what you are trying to do. I have forgotten to give a sample of the failing tests with the patch in comment 15: FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 38) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 44) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 48) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for excess errors) FAIL: gfortran.dg/abstract_type_4.f03 -O (test for excess errors) FAIL: gfortran.dg/abstract_type_6.f03 -O (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_5.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_6.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_alloc_expr_3.f90 -O (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_7.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_1.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_class_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/actual_array_constructor_1.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O0 (test for excess errors) ... With an additional filtering on (m == MATCH_ERROR), i.e. with the following patch, the ICEs are fixed without regression --- ../_clean/gcc/fortran/decl.c 2015-03-25 14:07:04.000000000 +0100 +++ gcc/fortran/decl.c 2015-04-05 16:17:34.000000000 +0200 @@ -4427,6 +4437,32 @@ ok: gfc_free_data_all (gfc_current_ns); cleanup: + //<pr59016> in gfc_match_data_decl; cleanup the garbages + gfc_symbol *csym = NULL; + if ((m == MATCH_ERROR) && current_ts.u.derived + && current_ts.u.derived->name) + { + char iname[129]; + iname[128] = 0; + for (int i = 0; i < 128; i++) + { + iname[i] = current_ts.u.derived->name[i]; + if (current_ts.u.derived->name[i] == 0) + break; + } + iname[0] = TOLOWER(iname[0]); + for (int i = 0; i < 4; i++) + { + gfc_find_symbol (iname, NULL, i, &csym) ; + if (csym && csym->generic + && (csym->generic->sym == current_ts.u.derived)) + { + csym->generic = NULL; + break; + } + } + } + //</pr59016> gfc_free_array_spec (current_as); current_as = NULL; return m; Further testing in progress. A few comments: (1) The patch could probably be simplified, (2) Its conformity with the GNU coding style has to be checked. (3) It has to go to fortran@gcc.gnu.org and gcc-patches@gcc.gnu.org for review. Ok, I'll send a patch to the recommended addresses as soon as I read the GNU coding standards. Yet, my impression is that perhaps the patch should be a bit more complex; in example, I think that the generic interface is introduced to a list and one has to remove it and restore to old value of the field "generic" to the symbol. Also, I think that the additional test could be: "( m != MATCH_OK )" Thank you for your patience to run the tests. > Also, I think that the additional test could be: "( m != MATCH_OK )"
I don't think so: the block in the patch will be reached for (m == MATCH_NO) and I think this leads to the regressions.
Created attachment 35232 [details]
cleanup if a declaration type spec is erroneous
Finally, I've sent for review to the recommended recipients the attached patch, which is suitable for gcc5.
Created attachment 35234 [details]
cleanup if a declaration type spec is erroneous
Let's see if the function names are properly printed into the context surrounding changes; the GNU patch guidelines suggest it!
*** Bug 65469 has been marked as a duplicate of this bug. *** Created attachment 35240 [details]
Cleaned patch
I have cleaned the patch along the Mikael's comment and fixed the test case.
Can we and do we commit this patch? I do very much appreciate Evangelos work here. I just do not understand where we are with copy right assignment status. Hello, It was my impression that small changes can be accepted by FSF without a copyright disclaimer or a copyright assignment on file, according to: https://gcc.gnu.org/contribute.html#legal So, my question is what the next action should be? Regards, Ev. Drikos On Apr 7, 2015, at 9:57 PM, jvdelisle at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 > > Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jvdelisle at gcc dot gnu.org > > --- Comment #25 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- > Can we and do we commit this patch? I do very much appreciate Evangelos work > here. I just do not understand where we are with copy right assignment status. > > -- > You are receiving this mail because: > You are on the CC list for the bug. Author: mikael Date: Fri Apr 10 11:29:53 2015 New Revision: 221972 URL: https://gcc.gnu.org/viewcvs?rev=221972&root=gcc&view=rev Log: PR fortran/56674 PR fortran/58813 PR fortran/59016 PR fortran/59024 fortran/ * symbol.c (save_symbol_data, gfc_save_symbol_data): Rename the former to the latter and make it non-static. Update callers. * gfortran.h (gfc_save_symbol_data): New prototype. * decl.c (gfc_match_decl_type_spec): Call 'gfc_save_symbol_data' before modifying symbols 'sym' and 'dt_sym'. testsuite/ * gfortran.dg/used_types_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/used_types_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog Author: mikael Date: Tue Apr 14 09:18:15 2015 New Revision: 222078 URL: https://gcc.gnu.org/viewcvs?rev=222078&root=gcc&view=rev Log: PR fortran/56674 PR fortran/58813 PR fortran/59016 PR fortran/59024 fortran/ * symbol.c (save_symbol_data, gfc_save_symbol_data): Rename the former to the latter and make it non-static. Update callers. * gfortran.h (gfc_save_symbol_data): New prototype. * decl.c (gfc_match_decl_type_spec): Call 'gfc_save_symbol_data' before modifying symbols 'sym' and 'dt_sym'. testsuite/ * gfortran.dg/used_types_27.f90: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/used_types_27.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/decl.c branches/gcc-4_9-branch/gcc/fortran/gfortran.h branches/gcc-4_9-branch/gcc/fortran/symbol.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog Author: mikael Date: Tue Apr 14 12:23:30 2015 New Revision: 222086 URL: https://gcc.gnu.org/viewcvs?rev=222086&root=gcc&view=rev Log: PR fortran/56674 PR fortran/58813 PR fortran/59016 PR fortran/59024 fortran/ * symbol.c (save_symbol_data, gfc_save_symbol_data): Rename the former to the latter and make it non-static. Update callers. * gfortran.h (gfc_save_symbol_data): New prototype. * decl.c (gfc_match_decl_type_spec): Call 'gfc_save_symbol_data' before modifying symbols 'sym' and 'dt_sym'. testsuite/ * gfortran.dg/used_types_27.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/used_types_27.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/decl.c branches/gcc-4_8-branch/gcc/fortran/gfortran.h branches/gcc-4_8-branch/gcc/fortran/symbol.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog *** Bug 56674 has been marked as a duplicate of this bug. *** *** Bug 58813 has been marked as a duplicate of this bug. *** *** Bug 59024 has been marked as a duplicate of this bug. *** Fixed for 5.1, 4.9.3, 4.8.5. Thanks for the bug report, and for the initial patches. |
gcc version 4.9.0 20131106 (experimental) [trunk revision 204433] (GCC) yields the following internal compiler error: f951: internal compiler error: Segmentation fault 0x9fee4f crash_signal ../../gcc/gcc/toplev.c:334 0x5ed8f9 gfc_sym_get_dummy_args(gfc_symbol*) ../../gcc/gcc/fortran/symbol.c:4572 0x5c73e1 resolve_fl_procedure ../../gcc/gcc/fortran/resolve.c:10971 0x5c73e1 resolve_symbol ../../gcc/gcc/fortran/resolve.c:13301 0x5e6233 do_traverse_symtree ../../gcc/gcc/fortran/symbol.c:3571 0x5d1477 resolve_types ../../gcc/gcc/fortran/resolve.c:14475 0x5c5aa3 gfc_resolve ../../gcc/gcc/fortran/resolve.c:14572 0x5c5aa3 gfc_resolve(gfc_namespace*) ../../gcc/gcc/fortran/resolve.c:14560 0x5bb30a gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4672 0x5f9c65 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:189 Please submit a full bug report, when compiling the invalid code below with gfortran -c -cpp bug.f90 > cat bug.f90 MODULE atomic_kind_types PUBLIC :: atomic_kind_type,& dft_plus_u_type CONTAINS SUBROUTINE get_atomic_kind_set(atomic_kind_set,maxatom,maxcgf,& zetsoft_max,basis_set_id) CALL stop_program(routineN,moduleN,__LINE__,& "The pointer atomic_kind_set is not associated") END SUBROUTINE get_atomic_kind_set PURE FUNCTION is_hydrogen(atomic_kind) RESULT(res) TYPE(atomic_kind_type), POINTER :: atomic_kind END FUNCTION is_hydrogen END MODULE atomic_kind_types It appears to be some corruption of some kind, since just compiling with gfortran -c bug.f90 does not ICE, instead contains some garbage string in the error message: 1 Error: Procedure '��XS0' in generic interface 'atomic_kind_type' at (1) is neither function nor subroutine Running under valgrind might help.