[Bug fortran/68053] lower bound of implied shape array restricted too much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68053 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/68053] lower bound of implied shape array restricted too much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68053 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Nov 9 06:06:52 2015 New Revision: 229993 URL: https://gcc.gnu.org/viewcvs?rev=229993=gcc=rev Log: 2015-11-08 Steven g. Kargl <ka...@gcc.gnu.org> PR fortran/68053 * decl.c (add_init_expr_to_sym): Try to reduce initialization expression before testing for a constant value. 2015-11-08 Steven g. Kargl <ka...@gcc.gnu.org> PR fortran/68053 * gfortran.dg/pr68053.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68053.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- Seems that in the case of errors, the clean up of the ref count is off by one.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-13 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- It seems that gfortran is missing a check for ENTRY. F2008 has C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt, entry-stmt, or stmt-function-stmt.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 13 00:14:32 2015 New Revision: 230278 URL: https://gcc.gnu.org/viewcvs?rev=230278=gcc=rev Log: 2015-11-12 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68318 * decl.c (get_proc_name): Increment reference count for ENTRY. While here, fix comment and use postfix ++ for consistency. 2015-11-12 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68318 * gfortran.dg/pr68318_1.f90: New test. * gfortran.dg/pr68318_2.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr68318_1.f90 trunk/gcc/testsuite/gfortran.dg/pr68318_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 13 01:11:10 2015 New Revision: 230282 URL: https://gcc.gnu.org/viewcvs?rev=230282=gcc=rev Log: 2015-11-12 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68318 * decl.c (get_proc_name): Increment reference count for ENTRY. While here, fix comment and use postfix ++ for consistency. 2015-11-12 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68318 * gfortran.dg/pr68318_1.f90: New test. * gfortran.dg/pr68318_2.f90: Ditto. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68318_1.f90 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68318_2.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- Working on this.
[Bug fortran/68237] ICE on invalid with submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> > This slightly changed test case should demonstrate the problem:
>
> Confirmed, the backtrace is
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0001000288c7 in gfc_match_submod_proc () at
> ../../work/gcc/fortran/decl.c:7649
> 7649if (sym->ts.interface->attr.function)
> (gdb) bt
> #0 0x0001000288c7 in gfc_match_submod_proc () at
> ../../work/gcc/fortran/decl.c:7649
> #1 0x000100082e8d in decode_statement () at
> ../../work/gcc/fortran/parse.c:384
> #2 0x000100084bc5 in next_statement () at
> ../../work/gcc/fortran/parse.c:1075
> #3 0x00010008b0f4 in parse_contained (module=) at
> ../../work/gcc/fortran/parse.c:4990
> #4 0x00010008c1df in parse_module () at
> ../../work/gcc/fortran/parse.c:5390
> #5 0x00010008cc43 in gfc_parse_file () at
> ../../work/gcc/fortran/parse.c:5696
> #6 0x0001000d39db in gfc_be_parse_file () at
> ../../work/gcc/fortran/f95-lang.c:205
> #7 0x000100aec62a in compile_file () at ../../work/gcc/toplev.c:466
> #8 0x000100fc173c in ?? ()
> #9 0x000100fc30f9 in main (argc=2, argv=0x7fff5fbff308) at
> ../../work/gcc/main.c:39
This patch
Index: decl.c
===
--- decl.c (revision 230336)
+++ decl.c (working copy)
@@ -7650,7 +7666,7 @@ gfc_match_submod_proc (void)
/* Make sure that the result field is appropriately filled, even though
the result symbol will be replaced later on. */
- if (sym->ts.interface->attr.function)
+ if (sym->ts.interface && sym->ts.interface->attr.function)
{
if (sym->ts.interface->result
&& sym->ts.interface->result != sym->ts.interface)
yields
troutmask:sgk[215] gfc6 -c k1.f90
k1.f90:14:19:
module procedure foo
1
Error: MODULE PROCEDURE at (1) must be in a generic module interface
k1.f90:15:6:
end procedure
1
Error: Expecting END SUBMODULE statement at (1)
Have no idea if it is correct. pault?
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 --- Comment #9 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 13 21:28:10 2015 New Revision: 230352 URL: https://gcc.gnu.org/viewcvs?rev=230352=gcc=rev Log: 2015-11-13 Steven G. Kargl <ka...@gccc.gnu.org> PR fortran/68319 * decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206. * io.c (gfc_match_format): Ditto. * match.c (gfc_match_st_function): Ditto. 2015-11-13 Steven G. Kargl <ka...@gccc.gnu.org> PR fortran/68319 * gfortran.dg/pr68319.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68319.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/fortran/io.c branches/gcc-5-branch/gcc/fortran/match.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #10 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have an ugly patch for this one.
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 13 21:11:42 2015 New Revision: 230351 URL: https://gcc.gnu.org/viewcvs?rev=230351=gcc=rev Log: 2015-11-13 Steven G. Kargl <ka...@gccc.gnu.org> PR fortran/68319 * decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206. * io.c (gfc_match_format): Ditto. * match.c (gfc_match_st_function): Ditto. 2015-11-13 Steven G. Kargl <ka...@gccc.gnu.org> PR fortran/68319 * gfortran.dg/pr68319.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr68319.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Nov 16 19:15:25 2015 New Revision: 230433 URL: https://gcc.gnu.org/viewcvs?rev=230433=gcc=rev Log: 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Nov 16 19:15:25 2015 New Revision: 230433 URL: https://gcc.gnu.org/viewcvs?rev=230433=gcc=rev Log: 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Nov 17 00:07:55 2015 New Revision: 230445 URL: https://gcc.gnu.org/viewcvs?rev=230445=gcc=rev Log: 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Nov 17 00:07:55 2015 New Revision: 230445 URL: https://gcc.gnu.org/viewcvs?rev=230445=gcc=rev Log: 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * expr.c (gfc_check_init_expr): Prevent a redundant check when a __convert_* function was inserted into an array constructor. (gfc_check_assign_symbol): Check for an initialization expression when a __convert_* was inserted. 2015-11-16 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/58027 PR fortran/60993 * gfortran.dg/pr58027.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr58027.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch.
[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #17 from kargl at gcc dot gnu.org --- I have a patch testing as I type.
[Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5.3 branch.
[Bug fortran/68382] Linux Binary Download page broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68382 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- The downloading of pre-built fortran is provided by a third party. Issues of this nature should be reported on the fortran@gcc mailing list not the bugzilla database.
[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68153 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- This one is interesting. gfc_check_reshape isn't checking 'sh' because it thinks 'sh' is a variable instead of a named constant. So, when gfc_simplify_reshape is called, it runs into an gcc_assert that the element is greater than zero because gfc_check_reshape should have emitted an error. If the gcc_assert is removed, an error message is generated.
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #20 from kargl at gcc dot gnu.org --- (In reply to neil.n.carlson from comment #19) > What is the status of this issue? It appears to not be completely fixed.
[Bug fortran/68151] ICE on using select case with function of wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68151 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68153 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/68224] ICE on referencing parameter array with dimension null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68224 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- I have a patch regression testing.
[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68153 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 7 20:18:17 2015 New Revision: 229939 URL: https://gcc.gnu.org/viewcvs?rev=229939=gcc=rev Log: 2015-11-07 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68153 * check.c (gfc_check_reshape): Improve check for valid SHAPE argument. 2015-11-07 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68153 * gfortran.dg/pr68153.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr68153.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68151] ICE on using select case with function of wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68151 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 7 20:04:43 2015 New Revision: 229938 URL: https://gcc.gnu.org/viewcvs?rev=229938=gcc=rev Log: 2015-11-07 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68151 * match.c (match_case_selector): Check for invalid type. 2015-11-07 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68151 * gfortran.dg/pr68151.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr68151.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68224] ICE on referencing parameter array with dimension null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68224 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- It appears that this needs to be fixed in match_array_element_spec. When the lower and upper array indices are matched, there is no checking for NULL(). NULL() is an interesting intrinsic function.
[Bug fortran/36192] ICE with wrong index types and bad parens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192 --- Comment #14 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 16:46:20 2015 New Revision: 229590 URL: https://gcc.gnu.org/viewcvs?rev=229590=gcc=rev Log: 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/36192 * interface.c (get_expr_storage_size): Check for INTEGER type before calling gmp routines. 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/36192 * gfortran.dg/pr36192_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr36192_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 16:26:59 2015 New Revision: 229588 URL: https://gcc.gnu.org/viewcvs?rev=229588=gcc=rev Log: 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68154 * decl.c (add_init_expr_to_sym): if the char length in the typespec is NULL, check for and use a constructor. 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68154 *gfortran.dg/pr68154.f90 Added: trunk/gcc/testsuite/gfortran.dg/pr68154.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46588] ICE with assumed character length function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46588 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 19:20:36 2015 New Revision: 229606 URL: https://gcc.gnu.org/viewcvs?rev=229606=gcc=rev Log: 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/46588 * gfortran.dg/pr46588.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr46588.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276 Bug 19276 depends on bug 46588, which changed state. Bug 46588 Summary: ICE with assumed character length function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46588 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/46588] ICE with assumed character length function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46588 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #4) > This appears to work now on trunk, but still > ICE's on 5-branch. My recent patches for > PR 67805 and friends may have fortuitously > fixed this PR. I've converted the code to a testcase and committed it to trunk. The bug is fixed in 5-branch, but Iwon't be committing the testcase to the branhc. Thanks for pointing out the bug.
[Bug fortran/36192] ICE with wrong index types and bad parens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192 --- Comment #15 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 16:58:20 2015 New Revision: 229591 URL: https://gcc.gnu.org/viewcvs?rev=229591=gcc=rev Log: 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/36192 * interface.c (get_expr_storage_size): Check for INTEGER type before calling gmp routines. 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/36192 * gfortran.dg/pr36192_1.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr36192_1.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/interface.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #9 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Sorry about the regression. Thanks for the bug report.
[Bug fortran/68154] [5/6 Regression] ICE on initializing character parameter array (explicit, implied)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68154 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 17:00:23 2015 New Revision: 229592 URL: https://gcc.gnu.org/viewcvs?rev=229592=gcc=rev Log: 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68154 * decl.c (add_init_expr_to_sym): if the char length in the typespec is NULL, check for and use a constructor. 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68154 * gfortran.dg/pr68154.f90 Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68154.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/36192] ICE with wrong index types and bad parens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #16 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 18:13:50 2015 New Revision: 229594 URL: https://gcc.gnu.org/viewcvs?rev=229594=gcc=rev Log: 2015-10-15 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/51993 * decl.c (gfc_set_constant_character_len): Convert gcc_assert into an if-statement causing an early return leads to valid error message. 2015-10-15 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/51993 * gfortran.dg/pr51993.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr51993.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from kargl at gcc dot gnu.org --- Change status.
[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > > Changing the gcc_assert to an early return gives ... > > Confirmed with the patch > > --- ../_clean/gcc/fortran/decl.c 2015-10-27 18:14:22.0 +0100 > +++ gcc/fortran/decl.c2015-10-29 12:02:02.0 +0100 > @@ -1293,7 +1293,9 @@ gfc_set_constant_character_len (int len, >int slen; > >gcc_assert (expr->expr_type == EXPR_CONSTANT); > - gcc_assert (expr->ts.type == BT_CHARACTER); > + /* gcc_assert (expr->ts.type == BT_CHARACTER); */ > + if (expr->ts.type != BT_CHARACTER) > +return; > >slen = expr->value.character.length; >if (len != slen) > > No regression. Yep, that's the patch I was testing. I'll submit shortly with a testcase.
[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 30 18:27:14 2015 New Revision: 229596 URL: https://gcc.gnu.org/viewcvs?rev=229596=gcc=rev Log: 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/51993 * decl.c (gfc_set_constant_character_len): Convert gcc_assert into an if-statement causing an early return leads to valid error message. 2015-10-30 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/51993 * gfortran.dg/pr51993.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr51993.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993 kargl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.3 --- Comment #9 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report. Sorry it took so long to fix.
[Bug fortran/67987] ICE on declaring and initializing character with negative len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67987 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > I have a patch that I'm testing. For the code in the > intial report I get > > troutmask:sgk[238] gfc6 -c g6.f90 > g6.f90:2:15: > > character(-8) :: c = ' ' >1 > Error: LEN at (1) must be greater than or equal to 0 Seems the patch causes a regression for char_length_2.f90. This test came in with the fix for PR fortran/31250, where negative length parameters are silently set to 0. The fix for this regression is in resolve.c. Unfortnately, this fix then exposes an issue with substring referecences. For "string"(1:-1), this should result in a 0 length string, but gfortran is setting the length to -1 in gfc_resolve_substring_charlen.
[Bug fortran/67988] ICE on accessing substring with negative range in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67988 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from kargl at gcc dot gnu.org --- The fix for 67987 fixes this problem. *** This bug has been marked as a duplicate of bug 67987 ***
[Bug fortran/67987] ICE on declaring and initializing character with negative len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67987 --- Comment #4 from kargl at gcc dot gnu.org --- *** Bug 67988 has been marked as a duplicate of this bug. ***
[Bug fortran/67885] ICE on using parameter array in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67885
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #1)
> Deleting this inner block gives another error :
>
> $ cat z5.f90
> program p
>block
> real, parameter :: a(2) = 1.0
> real :: x(2)
> x = a
> print *, x
>end block
> end
>
>
> $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z5.f90
> /tmp/cckgiZhq.o: In function `p':
> /home/.../z5.f90:5: undefined reference to `a.3386'
> collect2: error: ld returned 1 exit status
>
The a(2) appears to be optimized out. Don't know if the
code is legal because I haven't looked at standard, yet.
Changing your print statement to
if (x(1) /= 1.0) call abort
gives
% gfc6 -fdump-tree-original -c g5.f90
% cat g5.f90.003t.original
p ()
{
{
real(kind=4) x[2];
(void) __builtin_memcpy ((void *) , (void *) , 8);
if (x[0] != 1.0e+0)
{
_gfortran_abort ();
}
L.2:;
L.1:;
}
}
[Bug fortran/67987] ICE on declaring and initializing character with negative len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67987 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68019 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Oct 19 21:09:21 2015 New Revision: 229003 URL: https://gcc.gnu.org/viewcvs?rev=229003=gcc=rev Log: 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68019 * decl.c (add_init_expr_to_sym): Remove an assert() to allow an error message to be issued. 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68019 * gfortran.dg/pr68019.f90: new test. Added: trunk/gcc/testsuite/gfortran.dg/pr68019.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68019 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #4 from kargl at gcc dot gnu.org --- Thanks for the bug report. Fixed on trunk and 5-branch.
[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68019 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Oct 19 21:29:15 2015 New Revision: 229005 URL: https://gcc.gnu.org/viewcvs?rev=229005=gcc=rev Log: 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68019 * decl.c (add_init_expr_to_sym): Remove an assert() to allow an error message to be issued. 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/68019 * gfortran.dg/pr68019.f90: new test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68019.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67987] ICE on declaring and initializing character with negative len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67987 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Oct 19 18:15:36 2015 New Revision: 228999 URL: https://gcc.gnu.org/viewcvs?rev=228999=gcc=rev Log: 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67987 * decl.c (char_len_param_value): Unwrap unlong line. If LEN < 0, force it to zero per the Fortran 90, 95, 2003, and 2008 Standards. * resolve.c (gfc_resolve_substring_charlen): Unwrap unlong line. If 'start' is larger than 'end', length of substring is negative, so explicitly set it to zero. (resolve_charlen): Remove -Wsurprising warning. Update comment to reflect that the text is from the F2008 standard. 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67987 * gfortran.df/pr67987.f90: New test. * gfortran.dg/char_length_2.f90: Update testcase. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67987.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/fortran/resolve.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gfortran.dg/char_length_2.f90
[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68019 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-19 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.4, 5.2.1, 6.0 --- Comment #1 from kargl at gcc dot gnu.org --- An assert() is being triggered. If I comment out the assert(), I get % gfc6 -c g9.f90 g9.f90:7:31: type(t), parameter :: arr(*) = reshape(vec, [2, 2]) 1 Error: Incompatible ranks 1 and 2 in assignment at (1)
[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67900 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|4.9.4 |5.3 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67900 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Oct 20 00:45:48 2015 New Revision: 229014 URL: https://gcc.gnu.org/viewcvs?rev=229014=gcc=rev Log: 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67900 * resolve.c (gfc_verify_binding_labels): Check for NULL pointer. 2015-10-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67900 * gfortran.dg/pr67900.f90: New tests. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67900.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/resolve.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- The problem reported here seems to be fixed in 4.9.4, 5.2.1, and 6.0. No idea when or where it was fixed. The original testcase gives % gfc6 -w -c a3.f90 a3.f90:130:2: function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result( & 1 Error: Unclassifiable statement at (1) a3.f90:103:8: if (b1) then 1 Error: IF clause at (1) requires a scalar LOGICAL expression a3.f90:99:8: if (b) then 1 Error: IF clause at (1) requires a scalar LOGICAL expression Adding proper declarations for b and b1, then ends with % gfc6 -w -c a3.f90 a3.f90:132:2: function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result( & 1 Error: Unclassifiable statement at (1) Adding the missing 'retval) and 'end function', then yields something that compiles. Does the problem still exist?
[Bug fortran/67987] ICE on declaring and initializing character with negative len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67987 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-16 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.6.4, 4.7.4, 4.8.5, 4.9.4, ||5.2.1, 6.0 --- Comment #1 from kargl at gcc dot gnu.org --- I have a patch that I'm testing. For the code in the intial report I get troutmask:sgk[238] gfc6 -c g6.f90 g6.f90:2:15: character(-8) :: c = ' ' 1 Error: LEN at (1) must be greater than or equal to 0
[Bug fortran/67987] ICE on declaring and initializing character with negative len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67987 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Oct 17 16:50:47 2015 New Revision: 228933 URL: https://gcc.gnu.org/viewcvs?rev=228933=gcc=rev Log: 2015-10-17 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67987 * decl.c (char_len_param_value): Unwrap unlong line. If LEN < 0, force it to zero per the Fortran 90, 95, 2003, and 2008 Standards. * resolve.c (gfc_resolve_substring_charlen): Unwrap unlong line. If 'start' is larger than 'end', length of substring is negative, so explicitly set it to zero. (resolve_charlen): Remove -Wsurprising warning. Update comment to reflect that the text is from the F2008 standard. 2015-10-17 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67987 * gfortran.df/pr67987.f90: New test. * gfortran.dg/char_length_2.f90: Update testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr67987.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_length_2.f90
[Bug fortran/68005] internal compiler error with -O3 -g -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68005 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-17 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Travis Askham from comment #0) > Created attachment 36535 [details] > reproduces the compiler error with flags listed above > > internal compiler error: output_operand: floating constant misused > > This is the reported error for the attached example when compiled using: > > gfortran -c -g -O3 -fopenmp mincode.f > > All 3 flags are required to produce the error (also occurs with -O2 or -O1 > but not -O0) > > Version details: GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) Your code compile with 4.8.5, 4.9.4, 5.2.1, and 6.0.0 with the above options. Please update your compiler to a much newer version.
[Bug fortran/68005] internal compiler error with -O3 -g -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68005 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from kargl at gcc dot gnu.org --- Travis, thanks for the follow-up. I'm going to close this as fixed.
[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67900
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> The Ice appeared between revisions r199034 (2013-05-17):
>
> pr67900.f90:4.33:
>
> function f_real(x)
> 1
> pr67900.f90:9.36:
>
> function f_integer(x)
> 2
> Error: Binding label 'x' at (1) collides with global entity 'x' at (2)
>
> and r199221 (2013-05-17, ICE). Likely one of the revisions r199118, r199119,
> or r199120 (pr48858 and pr55465). I did not follow the convoluted arguments,
> but the code may be invalid: see the audit trail of the two PRs. Good Luck!
>
> Backtrace
>
> * thread #1: tid = 0x44d1226, 0x7fff90ac7bb0
> libsystem_platform.dylib`_platform_strcmp + 176, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
> frame #0: 0x7fff90ac7bb0 libsystem_platform.dylib`_platform_strcmp +
> 176
> libsystem_platform.dylib`_platform_strcmp:
> -> 0x7fff90ac7bb0 <+176>: movdqa (%rdi,%rcx), %xmm0
> 0x7fff90ac7bb5 <+181>: movdqu (%rsi,%rcx), %xmm1
> 0x7fff90ac7bba <+186>: pcmpeqb %xmm1, %xmm0
> 0x7fff90ac7bbe <+190>: pcmpeqb %xmm2, %xmm1
> (lldb) bt
> * thread #1: tid = 0x44d1226, 0x7fff90ac7bb0
> libsystem_platform.dylib`_platform_strcmp + 176, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
> * frame #0: 0x7fff90ac7bb0 libsystem_platform.dylib`_platform_strcmp +
> 176
> frame #1: 0x000100094f17 f951`(sym=0x000141f09680)(gfc_symbol *)
> + 599 at resolve.c:10783
> frame #2: 0x0001000bedac
> f951`::do_traverse_symtree(st=, st_func=,
> sym_func=(f951`(null)(gfc_symbol *) at resolve.c:10735))(gfc_symtree *),
> void (*)(gfc_symbol *)) + 236 at symbol.c:3703
> frame #3: 0x0001000a7f54 f951`::resolve_types(ns=) +
> 1028 at resolve.c:15336
> frame #4: 0x0001000a3458 f951`gfc_resolve(ns=0x000142015400) +
> 56 at resolve.c:15416
> frame #5: 0x0001000a662f
> f951`::resolve_symbol(sym=0x000141f09550) + 8479 at resolve.c:13362
> frame #6: 0x0001000bedac
> f951`::do_traverse_symtree(st=, st_func=,
> sym_func=(f951`::resolve_symbol(gfc_symbol *) at
> resolve.c:13482))(gfc_symtree *), void (*)(gfc_symbol *)) + 236 at
> symbol.c:3703
> frame #7: 0x0001000a7d15 f951`::resolve_types(ns=0x00014480)
> + 453 at resolve.c:15306
> frame #8: 0x0001000a3458 f951`gfc_resolve(ns=0x00014480) +
> 56 at resolve.c:15416
> frame #9: 0x00010008c03b f951`gfc_parse_file() [inlined]
> resolve_all_program_units(gfc_global_ns_list=0x00014480) + 71 at
> parse.c:5485
> frame #10: 0x00010008bff4 f951`gfc_parse_file() + 1044
> frame #11: 0x0001000d19b6 f951`::gfc_be_parse_file() + 54 at
> f95-lang.c:209
> frame #12: 0x00010091e89a f951`::compile_file() + 58 at toplev.c:483
> frame #13: 0x000100cfddbc f951`toplev::main(int, char**) + 1151 at
> toplev.c:1973
> frame #14: 0x000100cfd93d f951`toplev::main(this=,
> argc=2, argv=0x7fff5fbff350) + 717
> frame #15: 0x000100cff779 f951`main(argc=2, argv=0x7fff5fbff350)
> + 41 at main.c:39
Patch
Index: resolve.c
===
--- resolve.c (revision 228206)
+++ resolve.c (working copy)
@@ -10702,7 +10702,7 @@ gfc_verify_binding_labels (gfc_symbol *s
sym->binding_label = NULL;
}
- else if (sym->attr.flavor == FL_VARIABLE
+ else if (sym->attr.flavor == FL_VARIABLE && module
&& (strcmp (module, gsym->mod_name) != 0
|| strcmp (sym->name, gsym->sym_name) != 0))
{
[Bug fortran/68268] configure: error: GNU Fortran is not working;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268 --- Comment #9 from kargl at gcc dot gnu.org --- (In reply to isearcher from comment #8) > Now here is a new problem. Gfortran can now produce the a.out, but when i > run ./a.out, there is an error: > > ./a.out: error while loading shared libraries: libgfortran.so.3: cannot open > shared object file: No such file or directory > > Ahy sugguestions? GCC bugzilla is not a user support forum. Post to gcc-help with questions of this nature. The answer to your question lies in the ldconfig documentation.
[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59910 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have a patch for this problem.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 14 17:31:16 2015 New Revision: 230379 URL: https://gcc.gnu.org/viewcvs?rev=230379=gcc=rev Log: 2015-11-14 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67803 * array.c (gfc_match_array_constructor): If array constructor included a CHARACTER typespec, check array elements for compatible type. 2015-11-14 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67803 * gfortran.dg/pr67803.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr67803.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 14 17:43:15 2015 New Revision: 230380 URL: https://gcc.gnu.org/viewcvs?rev=230380=gcc=rev Log: 2015-11-14 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67803 * array.c (gfc_match_array_constructor): If array constructor included a CHARACTER typespec, check array elements for compatible type. 2015-11-14 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67803 * gfortran.dg/pr67803.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67803.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/array.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67367] Program crashes on READ(IOSTAT=IOS, ...) on directory OPEN()ed without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67367 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #1) Program received signal SIGSEGV, Segmentation fault. 0x77ba152e in buf_read (s=0x6063b0, buf=optimized out, nbyte=optimized out) at ../../../trunk/libgfortran/io/unix.c:535 535 memcpy (p, s-buffer, did_read); There are a bunch of bugs lurking in fortran/io.c. For example, flush(iostat=ios) causes a problem.
[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Resolved as WONTFIX? Probably not. See the last 2 paragraphs in comment #1.
[Bug fortran/67429] [5/6 Regression] Missing part of error messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67429 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #0) > When compiling the test in pr65045 with r218570 I get the errors > So, why isn't this a duplicate of PR65045?
[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430 kargl at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal
[Bug fortran/67444] RHS of overloaded assignment not finalized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67444 kargl at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal
[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Resolution|INVALID |FIXED --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Boris Carlsson from comment #0) > The assembler code implementation for > > subroutine move_buggy(a, b, n) > integer :: n, i > integer, dimension(*) :: a, b > do i = 1, n > a(i) = b(i) > end do > end subroutine move_buggy > > generated with > > gfortran -S move_buggy.f90 -O3 > > or more "condensed" with > > gfortran -S move_buggy.f90 -O1 -ftree-loop-distribute-patterns > -foptimize-sibling-calls -fstrict-overflow > > will replace the loop with a call to memcpy. memcpy is not guaranteed to > work if the memory locations for a and b overlap, which could be the case > here. Thus, the above code will not execute as expected (depending on the > implementation of memcpy) when these optimizations are used. Thus, memcpy > should not be used here. > > The bug is present in gfortran 5.2.1 and 4.9.3 (details below) but NOT in > 4.7.2. > The memory locations for a and b cannot overlap in standard conforming code. This restriction goes back to at least Fortran 77, and it is a restriction on the programmer not the compiler.
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Sep 10 17:13:11 2015 New Revision: 227651 URL: https://gcc.gnu.org/viewcvs?rev=227651=gcc=rev Log: 2015-09-09 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67526 * gfortran.dg/pr67526.f90: New test. 2015-09-09 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67526 * expr.c (gfc_check_init_expr): Do not dereference a NULL pointer. Added: trunk/gcc/testsuite/gfortran.dg/pr67526.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/67525] ICE on select type with improper selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67525 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-09 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- Confirmed. I have a patch.
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Sep 10 18:07:07 2015 New Revision: 227655 URL: https://gcc.gnu.org/viewcvs?rev=227655=gcc=rev Log: 2015-09-09 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67526 * gfortran.dg/pr67526.f90: New test. 2015-09-09 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67526 * expr.c (gfc_check_init_expr): Do not dereference a NULL pointer. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67526.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67538] ICE with invalid source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67538 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > > The following code is invalid since the array dimension is missing, > > but since it is an ICE I am reporting it. > > This is valid since F2003 (implemented recently by Andre Vehreschild), but > it should not give an ICE. Are you sure? There is no array spec. real, allocatabe :: x(:) ! Rank 1 real y y = 42! Rank 0 allocate(x , source=y) What are the ubound and lbound of x?
[Bug fortran/67588] module.c heap use after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-15 CC||kargl at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Paul, I think Vittorio is correct. It appears you meant to free a list, but you only free the head and then leak memory.
[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #0) > During "make check" a null pointer is sometimes passed to memcpy in > write.c:1877 > > memcpy (ext_name, base_name, base_name_len); > > because base_name == NULL > > but base_name_len == 0 so it should be harmless. > To make happy the sanitizer the statement should be > > if(base_name_len) memcpy (ext_name, base_name, base_name_len); What happens to performance? Simply making changes to make sanitizer happy seems rather questionable. It's clear from context that if base_name == NULL, then base_name_len == 0, and the memcpy should be a NOP.
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for bug report.
[Bug fortran/66979] gfortran internal compiler error with malformed FLUSH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66979 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Known to fail||4.7.4, 4.8.5, 4.9.4, 5.2.1, ||6.0 --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) > > > Resolved as WONTFIX? > > > > Probably not. See the last 2 paragraphs in comment #1. > > Sorry, but my question was motivated by the reading of these two > paragraphs!-( > Thus two more explicit questions: > > (1) Shall I submit a patch to replace in the manual all the "Fortran 95 and > later" with "Fortran 90 and later" where appropriate? No. gfortran never tried to address the Fortran 90 standard. Whatever is stated in F90 is irrelevant to the extent that gfortran is a Fortran 95 compiler and F90 beget F95. > > (2) Shall I submit a patch to replace > > The Fortran 2003 standard specifies the intrinsic RANDOM_SEED to initialize > the pseudo-random numbers generator and RANDOM_NUMBER to generate > pseudo-random numbers. > > with > > The Fortran 9? standard specifies the intrinsic RANDOM_SEED to initialize > the pseudo-random numbers generator and RANDOM_NUMBER to generate > pseudo-random numbers. These intrinsics should be used in new codes. > I would not not call out a particular standard version. Probably something like The Fortran standard specifies the intrinsic subroutine RANDOM_SEED to initialize the pseudo-random numbers generator and the intrinsic subroutine RANDOM_NUMBER to generate pseudo-random numbers. These subroutines should be used in new codes.
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-01 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.6.4, 4.7.4, 4.8.5, 4.9.4, ||5.2.1, 6.0
[Bug fortran/67802] ICE on initializing character with wrong len type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67802 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-01 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.6.4, 4.7.4, 4.8.5, 4.9.4, ||5.2.1, 6.0 --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/67616] ICE on data initialization of type variable in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 2 00:45:59 2015 New Revision: 228363 URL: https://gcc.gnu.org/viewcvs?rev=228363=gcc=rev Log: 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67616 * primary.c (gfc_match_structure_constructor): Use a possibly host-associated symtree to prevent ICE. 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67616 * gfortran.dg/pr67616.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr67616.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66979] gfortran internal compiler error with malformed FLUSH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66979 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 2 00:49:28 2015 New Revision: 228364 URL: https://gcc.gnu.org/viewcvs?rev=228364=gcc=rev Log: 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/66979 * io.c (gfc_resolve_filepos): Check for a UNIT number. Add a nearby missing 'return false'. 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/66979 gfortran.dg/pr66979.f90: new test. Added: trunk/gcc/testsuite/gfortran.dg/pr66979.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66979] gfortran internal compiler error with malformed FLUSH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66979 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 2 20:19:32 2015 New Revision: 228423 URL: https://gcc.gnu.org/viewcvs?rev=228423=gcc=rev Log: 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/66979 * io.c (gfc_resolve_filepos): Check for a UNIT number. Add a nearby missing 'return false'. 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/66979 gfortran.dg/pr66979.f90: new test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr66979.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/io.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67802] ICE on initializing character with wrong len type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67802 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 2 21:27:02 2015 New Revision: 228430 URL: https://gcc.gnu.org/viewcvs?rev=228430=gcc=rev Log: 2015-10-02 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67802 * decl.c (add_init_expr_to_sym): Numeric constant for character length must be an INTEGER. 2015-10-02 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67802 * gfortran.dg/pr67802.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67802.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66979] gfortran internal compiler error with malformed FLUSH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66979 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66495] [5 Regression] Issue with same name for embedded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66495 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > The ICE appeared between revisions r218570 (2014-12-10, no ICE) and r218658 > (2014-12-12, ICE), likely r218627 (pr44054) or a related commit. > > This has been fixed between r223447 (2015-05-20, ICE) and r224148 > (2015-06-05, no ICE), likely r223614. I doubt the r223614 will be back ported. This should probably closed as fixed on trunk. If no one objects I'll close this PR in a few days.
[Bug fortran/67802] ICE on initializing character with wrong len type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67802 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/67616] ICE on data initialization of type variable in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66969] Internal compiler error, segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66969 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I believe the code is invalid. Here a small rewrite program bug implicit none real, target, allocatable :: a(:,:) allocate(a(10,10)) a = 1.0 print*, f(a) contains function f(b) result(x) real, target, intent(in):: b(:,:) real, pointer :: c(:,:) real :: x(size(c(1,:))) c => b(1:2,:) x = c(2,:) end function f end program bug The line 'real :: x(size(c(1,:))' is referencing an unassociated pointer. If I add the 'integer :: n = size(c(1,:)) I get % gfc6 -c bug.f90 bug.f90:15:29: integer :: n = size(c(1,:)) 1 Error: Deferred array 'c' at (1) is not permitted in an initialization expression A similar error should probably occur here.
[Bug fortran/67616] ICE on data initialization of type variable in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 2 21:11:47 2015 New Revision: 228427 URL: https://gcc.gnu.org/viewcvs?rev=228427=gcc=rev Log: 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67616 * primary.c (gfc_match_structure_constructor): Use a possibly host-associated symtree to prevent ICE. 2015-10-01 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/67616 * gfortran.dg/pr67616.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67616.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/primary.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66461] [4.9/5/6 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
The bug surfaces at line 1439 in match.c. The line is
gfc_match (" if ( %e ) ", ); /* Guaranteed to match. */
The comment is wrong. For some reason, splitting
the expression across the two lines causes a match
failure. Changing the above to
m = gfc_match (" if ( %e ) ", );
if (m != MATCH_YES)
return m;
yields
troutmask:sgk[232] gfc6 -c g5.f
g5.f:5:72:
Error: Syntax error in expression at (1)
f951: Error: Unexpected end of file in 'g5.f'
which yields a bogus error and the desired error.
[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> WORKSFORME!
>
> pr67758.f90:1:26:
>
>COMMON /FMCOM / X(80 000 000)
> 1
> Error: Expected another dimension in array declaration at (1)
> pr67758.f90:3:24:
>
>COMMON /FMCOM / XX(80 000 000)
> 1
> Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
>
> with r227016 (2015-08-19) and all the revisions I have tested (I have added
> an END statement). Could you please post the output of 'gfortran -v'?
troutmask:sgk[204] gfc6 -c r5.f
f951: internal compiler error: Segmentation fault
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
troutmask:sgk[205] gfc5 -c r5.f
r5.f:3:24:
COMMON /FMCOM / XX(80 000 000)
1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
f951: Error: Unexpected end of file in 'r5.f'
troutmask:sgk[206] gfc49 -c r5.f
r5.f:3.24:
COMMON /FMCOM / XX(80 000 000)
1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
Error: Unexpected end of file in 'r5.f'
Looks like a regression in symbol.c.
(gdb) p p->common_block->head->common_next
$9 = (gfc_symbol *) 0x0
(gdb) list
3205 else
3206{
3207 gfc_symbol *cparent, *csym;
3208
3209 cparent = p->common_block->head;
3210 csym = cparent->common_next;
3211
3212 while (csym != p)
3213{
3214 cparent = csym;
3215 csym = csym->common_next;
3216}
3217
3218 gcc_assert(cparent->common_next == p);
3219 cparent->common_next = csym->common_next;
3220}
3221}
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-09 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch.
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 36314 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36314=edit patch The attached patch fixes the dereference of a NULL pointer.
[Bug fortran/67528] Wrong result with defined assignment operator and/or parenthesized expressions and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67528 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-09 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Possible patch https://gcc.gnu.org/ml/fortran/2015-09/msg00058.html The essence of the issue is that the assignments aren't being translates to the call. v1 = v1 --> call copy_t_a(v1, (v1)) vi = (v1) --> call copy_t_a(vi, ((v1)))
[Bug fortran/67528] Wrong result with defined assignment operator and/or parenthesized expressions and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67528 --- Comment #2 from kargl at gcc dot gnu.org --- This bug report appears to be a related to PR59202 and may be a duplicate.
