* [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
@ 2015-09-29 17:35 ` dominiq at lps dot ens.fr
2015-09-29 19:56 ` kargl at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-29 17:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2015-09-29
Summary|[GCC 6 regression] ICE on |[GCC 6 regression] ICE on
|invalid code |invalid use of COMMON
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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'?
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
2015-09-29 17:35 ` [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON dominiq at lps dot ens.fr
@ 2015-09-29 19:56 ` kargl at gcc dot gnu.org
2015-09-29 20:24 ` sgk at troutmask dot apl.washington.edu
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu.org @ 2015-09-29 19:56 UTC (permalink / raw)
To: gcc-bugs
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 }
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
2015-09-29 17:35 ` [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON dominiq at lps dot ens.fr
2015-09-29 19:56 ` kargl at gcc dot gnu.org
@ 2015-09-29 20:24 ` sgk at troutmask dot apl.washington.edu
2015-09-29 23:03 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2015-09-29 20:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Sep 29, 2015 at 07:56:16PM +0000, kargl at gcc dot gnu.org wrote:
>
> 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.
This fixes the regression.
Index: symbol.c
===================================================================
--- symbol.c (revision 228264)
+++ symbol.c (working copy)
@@ -3211,6 +3211,8 @@ gfc_restore_last_undo_checkpoint (void)
while (csym != p)
{
+ if (!csym)
+ goto syntax;
cparent = csym;
csym = csym->common_next;
}
@@ -3242,6 +3244,11 @@ gfc_restore_last_undo_checkpoint (void)
if (!single_undo_checkpoint_p ())
pop_undo_change_set (latest_undo_chgset);
+
+ return;
+
+syntax:
+ gfc_error ("syntax or semantics issue at %C");
}
But, the real issue is that the second COMMON is not
allowed to appear in the execution block of a program.
gfortran should probably error out earlier.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
` (2 preceding siblings ...)
2015-09-29 20:24 ` sgk at troutmask dot apl.washington.edu
@ 2015-09-29 23:03 ` dominiq at lps dot ens.fr
2015-10-04 12:30 ` mikael at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-29 23:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
OK. I can reproduce the ICE in free form (*.f90) by replacing '80 000 000' with
'80000000'. The change occurred between r226476 (2015-08-02, error) and r227016
(2015-08-19, ICE), likely r226732 (pr59746).
> But, the real issue is that the second COMMON is not
> allowed to appear in the execution block of a program.
> gfortran should probably error out earlier.
Agreed, although the original error
Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
may not be obvious to understand.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
` (3 preceding siblings ...)
2015-09-29 23:03 ` dominiq at lps dot ens.fr
@ 2015-10-04 12:30 ` mikael at gcc dot gnu.org
2015-10-05 14:56 ` mikael at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-10-04 12:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sun Oct 4 12:30:16 2015
New Revision: 228457
URL: https://gcc.gnu.org/viewcvs?rev=228457&root=gcc&view=rev
Log:
Fix fortran common-related error recovery ICE.
Upon reverting a symbol in a common block (after throwing an error),
the compiler was ICEing because the symbol's common_block field was set,
but the symbol was not in the common block's list of symbols.
Fixed by both adding the symbol to the common block list and setting
the symbol's common_block field at the same time.
Furthermore, the gfc_add_in_common call is delayed and its result is
ignored, so that its error messages are ignored and the compiler has
the opportunity to give a better error message.
Another gfc_add_in_common call is added later during resolution
to emit again the missing errors.
PR fortran/67758
gcc/fortran/
* match.c (gfc_match_common): Delay the common_block pointer
assignment after error checking.
Delay the call to gfc_add_in_common attribute after the handling
of array specs.
* resolve.c (resolve_common_vars): Call gfc_add_in_common again.
gcc/testsuite/
* gfortran.dg/common_24.f: New.
Added:
trunk/gcc/testsuite/gfortran.dg/common_24.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
` (4 preceding siblings ...)
2015-10-04 12:30 ` mikael at gcc dot gnu.org
@ 2015-10-05 14:56 ` mikael at gcc dot gnu.org
2015-10-16 8:31 ` [Bug fortran/67758] [6 Regression] " rguenth at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-10-05 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|kargl at gcc dot gnu.org |mikael at gcc dot gnu.org
--- Comment #7 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #6)
> If I compile the test as free form before r228458, I get the following ICE
>
You're right, the fix needs a fix.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [6 Regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
` (5 preceding siblings ...)
2015-10-05 14:56 ` mikael at gcc dot gnu.org
@ 2015-10-16 8:31 ` rguenth at gcc dot gnu.org
2015-10-18 17:18 ` mikael at gcc dot gnu.org
2015-10-18 18:20 ` mikael at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-16 8:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-invalid-code
Priority|P3 |P4
Target Milestone|--- |6.0
Summary|[GCC 6 regression] ICE on |[6 Regression] ICE on
|invalid use of COMMON |invalid use of COMMON
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [6 Regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
` (6 preceding siblings ...)
2015-10-16 8:31 ` [Bug fortran/67758] [6 Regression] " rguenth at gcc dot gnu.org
@ 2015-10-18 17:18 ` mikael at gcc dot gnu.org
2015-10-18 18:20 ` mikael at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-10-18 17:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sun Oct 18 17:17:21 2015
New Revision: 228947
URL: https://gcc.gnu.org/viewcvs?rev=228947&root=gcc&view=rev
Log:
Fix common-related error recovery ICE.
Fix an inconsistent state, between the in_common attribute
and the common_block pointer.
- adding a symbol to a common block list in gfc_match_common is delayed
after the call to gfc_add_in_common.
- gfc_restore_latest_undo_checkpoint is changed to check the common_block
pointer directly instead of the in_common attribute.
- gfc_restore_old_symbol is changed to also restore
the common-related pointers. This is done using a new function created
to factor the related memory management.
- In gfc_restore_last_undo_checkpoint, when a symbol has been removed
from the common block linked list, its common_next pointer is cleared.
PR fortran/67758
gcc/fortran/
* gfortran.h (gfc_symbol): Expand comment.
* match.c (gfc_match_common): Delay adding the symbol to
the common_block after the gfc_add_in_common call.
* symbol.c (gfc_free_symbol): Move common block memory handling...
(gfc_set_symbol_common_block): ... here as a new function.
(restore_old_symbol): Restore common block fields.
(gfc_restore_last_undo_checkpoint):
Check the common_block pointer instead of the in_common attribute.
When a symbol has been removed from the common block linked list,
clear its common_next pointer.
gcc/testsuite/
* gfortran.dg/common_25.f90: New file.
Added:
trunk/gcc/testsuite/gfortran.dg/common_25.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug fortran/67758] [6 Regression] ICE on invalid use of COMMON
2015-09-29 10:05 [Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code ienkovich at gcc dot gnu.org
` (7 preceding siblings ...)
2015-10-18 17:18 ` mikael at gcc dot gnu.org
@ 2015-10-18 18:20 ` mikael at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-10-18 18:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67758
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
This should be fixed now.
^ permalink raw reply [flat|nested] 10+ messages in thread