[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #12 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/96099] ICE in gfc_validate_kind, at fortran/trans-types.c:773

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
@@ -2858,7 +2858,8 @@ variable_decl (int elem)
 {
   if (gfc_match (" =>") == MATCH_YES)
{
- if (!current_attr.pointer)
+ gfc_find_symbol (name, gfc_current_ns, 1, );
+ if (!(current_attr.pointer || (sym && sym->attr.pointer)))
{
  gfc_error ("Initialization at %C isn't for a pointer variable");
  m = MATCH_ERROR;

The contents of current_attr only applies to the line currently being parsed so
will not have the pointer attribute.  In the case where the pointer attribute
has already been declared a matching symbol should exist that has that
attribute set.

However, if the pointer attribute is declared after the initialisation it is
not known when initialisation line is parsed.  The parsing of pointer occurs
after the initialisation parsing is complete.

For this to be fixed where the attribute is declared after initialisation error
detection would have to be deferred until after parsing has been completed.

The above change does not result in any unexpected test case failures when
running make with check-fortran.

I'm no longer working on this PR as I do not know how to proceed.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #10 from markeggleston at gcc dot gnu.org ---
See 97224

[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Reopened 95614

[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721

--- Comment #11 from markeggleston at gcc dot gnu.org ---
No progress. I have no idea how to fix this and will no longer work on it.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[markeggleston at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #9 from markeggleston at gcc dot gnu.org ---
Committed to master and backported.