[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Mikael Morin changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.8.5 --- Comment #33 from Mikael Morin --- Fixed for 5.1, 4.9.3, 4.8.5. Thanks for the bug report, and for the initial patches.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Mikael Morin changed: What|Removed |Added CC||kimwooyoung at gmail dot com --- Comment #32 from Mikael Morin --- *** Bug 59024 has been marked as a duplicate of this bug. ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Mikael Morin changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #31 from Mikael Morin --- *** Bug 58813 has been marked as a duplicate of this bug. ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #30 from Mikael Morin --- *** Bug 56674 has been marked as a duplicate of this bug. ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #29 from Mikael Morin --- 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 fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #28 from Mikael Morin --- 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
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #26 from drikosev at otenet dot gr --- 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 wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 > > Jerry DeLisle changed: > > What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #25 from Jerry DeLisle --- > 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.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #25 from Jerry DeLisle --- 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.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #24 from Dominique d'Humieres --- Created attachment 35240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35240&action=edit Cleaned patch I have cleaned the patch along the Mikael's comment and fixed the test case.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #23 from Dominique d'Humieres --- *** Bug 65469 has been marked as a duplicate of this bug. ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #22 from drikosev at otenet dot gr --- Created attachment 35234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35234&action=edit 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 fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #21 from drikosev at otenet dot gr --- Created attachment 35232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35232&action=edit 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.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #20 from Dominique d'Humieres --- > 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.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #19 from drikosev at otenet dot gr --- 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.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #18 from Dominique d'Humieres ---
With an additional filtering on (m == MATCH_ERROR), i.e. with the following
patch, the ICEs are fixed without regression
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/decl.c2015-04-05 16:17:34.0 +0200
@@ -4427,6 +4437,32 @@ ok:
gfc_free_data_all (gfc_current_ns);
cleanup:
+ // 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;
+ }
+}
+}
+ //
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 fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org for review.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #17 from Dominique d'Humieres --- 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: g
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #16 from Dominique d'Humieres ---
> 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.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/decl.c2015-04-05 13:02:38.0 +0200
@@ -4427,6 +4427,31 @@ ok:
gfc_free_data_all (gfc_current_ns);
cleanup:
+ // 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;
+ }
+}
+}
+ //
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.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #15 from drikosev at otenet dot gr --- Created attachment 35230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35230&action=edit 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).
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #14 from drikosev at otenet dot gr --- Indeed, the new patch in comment 10 does not prevent the ICEs with the the first example bug.f90 (in Description before comment 1).
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #13 from drikosev at otenet dot gr --- 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
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Dominique d'Humieres changed: What|Removed |Added CC||daniel.price at monash dot edu --- Comment #12 from Dominique d'Humieres --- *** Bug 65469 has been marked as a duplicate of this bug. ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #11 from Dominique d'Humieres --- > 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 fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #10 from drikosev at otenet dot gr --- Created attachment 35226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35226&action=edit 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
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #9 from Dominique d'Humieres ---
I have tested on trunk (5.0) the following variant
--- ../_clean/gcc/fortran/interface.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/interface.c2015-03-30 10:05:08.0 +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)
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #8 from drikosev at otenet dot gr --- 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)
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #7 from drikosev at otenet dot gr ---
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!
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 drikosev at otenet dot gr changed: What|Removed |Added CC||drikosev at otenet dot gr --- Comment #6 from drikosev at otenet dot gr --- Created attachment 35171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35171&action=edit 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
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2013-11-17 00:00:00 |2014-12-6 CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #5 from Joost VandeVondele --- 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,
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #4 from Dominique d'Humieres --- Backtrace is Program received signal SIGSEGV, Segmentation fault. error_print(const char *, const char *, typedef __va_list_tag __va_list_tag *) (type=, format0=, argp=) 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=, format0=, argp=) at ../../work/gcc/fortran/error.c:173 #1 0x00010002fa4e in gfc_error (gmsgid=) at ../../work/gcc/fortran/error.c:1003 #2 0x00010003827c in check_interface0 (p=0x141f05ad0, interface_name=0x7fff5fbff060 "generic interface 'atomic_kind_type'") at ../../work/gcc/fortran/interface.c:1568 #3 0x00010003b243 in check_sym_interfaces (sym=0x25) at ../../work/gcc/fortran/interface.c:1680 #4 0x0001000a98dc in do_traverse_symtree (st=, st_func=, sym_func=) at ../../work/gcc/fortran/symbol.c:3575 #5 0x00010003c01c in gfc_check_interfaces (ns=0x143020c00) at ../../work/gcc/fortran/interface.c:1790 #6 0x000100094071 in resolve_types (ns=) at ../../work/gcc/fortran/resolve.c:14589 #7 0x00010008f9eb in gfc_resolve (ns=) at ../../work/gcc/fortran/resolve.c:14670 #8 0x00010007a0a1 in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4672 #9 0x0001000bc7f6 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:188 #10 0x00010084c924 in compile_file () at ../../work/gcc/toplev.c:547 #11 0x00010084ebe9 in toplev_main (argc=2, argv=0x7fff5fbff4d0) at ../../work/gcc/toplev.c:1887
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #3 from Dominique d'Humieres --- 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
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Bud Davis changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis --- Is the reduced test case valid code ? Should it compile cleanly or should it provide a warning or error ?
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-17 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- 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
