[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #8) > Potential fix for comment#0: I'm getting many regressions for this change. Investigating.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #8 from anlauf at gcc dot gnu.org --- Potential fix for comment#0: diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index bed61e2325d..54309646aad 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -709,6 +709,11 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) } } + /* Implicit SAVE (F2018, 8.5.16 SAVE attribute, clause 4). */ + if (sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program + && sym->attr.save == SAVE_NONE) +sym->attr.save = SAVE_IMPLICIT; + /* Derived types are a bit peculiar because of the possibility of a default initializer; this must be applied each time the variable comes into scope it therefore need not be static. These variables Works for me, but not regtested yet. Does that help? Of course that handles only part of that clause, and we need extended testcases.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a
Looking at the tree dump, it appears that there is a latent issue.
void MAIN__ ()
{
real(kind=4) a[16776325];
However, that standard says:
F2018 8.5.16 SAVE attribute
(4) A variable, common block, or procedure pointer declared in the scoping unit
of a main program, [...] implicitly has the SAVE attribute
My interpretations of the issue is that we miss to set the SAVE_IMPLICIT,
which is confirmed by running under the debugger, which shows that a
has SAVE_NONE.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Jakub Jelinek changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #5 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #4) > And you are trying to use 65532 kbytes long array on the stack, leaving no > stack space for anything else. Clearly user error. out of curiosity, why did this work previously? (was the array previously allocated on the heap?) we are not being very helpful to the user who made the error (neither Linux nor Darwin give any stack overflow), but I guess that's hard to arrange robustly.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- And you are trying to use 65532 kbytes long array on the stack, leaving no stack space for anything else. Clearly user error.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #3 from Dominique d'Humieres --- > What is your stack size? 65532 kbytes > Does it help if you declare a SAVEd? The illegal instruction is gone.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #2 from anlauf at gcc dot gnu.org --- What is your stack size? Does it help if you declare a SAVEd?
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Iain Sandoe changed: What|Removed |Added Target||x86_64-darwin, ||x86_64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-16 Ever confirmed|0 |1 Keywords||wrong-code CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- also fails on x86_64 linux (with a segv rather than a ill). Linux: (gdb) r Starting program: /home/iains/t Program received signal SIGSEGV, Segmentation fault. 0x0040118c in MAIN__ () at dom1.f90:2 2 a=1.0_8 Darwin: Process 14098 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeebbff900) frame #0: 0x00010ec2 t`MAIN__ at dom1.f90:2:7 1REAL(KIND=4) :: a(16,1024,1024), s -> 2a=1.0_8 3END Target 0: (t) stopped.
