https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #14 from G. Steinmetz ---
$ cat z3.f90
program p
character(:), pointer :: c
common c
n = len(c)
end
$ gfortran-10-20191201 -c z3.f90
z3.f90:4:0:
4 |n = len(c)
|
internal compiler error: in gfc_conv_intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #13 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #12 from Jürgen Reuter ---
This is still present. Any progress?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #11 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #10)
> Interestingly, nagfor rejects this code with the message "Inconsistent
> definitions of COMMON block FOO in program-units $block and BAR". Both ifort
> and pgfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #10 from Jürgen Reuter ---
Interestingly, nagfor rejects this code with the message "Inconsistent
definitions of COMMON block FOO in program-units $block and BAR". Both ifort
and pgfortran compile the code, and the program issues 'ABC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #9 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #7)
> Ah sorry, I think I moved around the block data and then it wasn't valid
> Fortran anymore. I think, both the block data and the subroutine are
> external to the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #8 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #7)
> Ah sorry, I think I moved around the block data and then it wasn't valid
> Fortran anymore. I think, both the block data and the subroutine are
> external to the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #7 from Jürgen Reuter ---
Ah sorry, I think I moved around the block data and then it wasn't valid
Fortran anymore. I think, both the block data and the subroutine are external
to the main program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #6 from Dominique d'Humieres ---
> In the recent trunk (r264725) does _not_ give an ICE anymore, but the code
> is vetoed as non-standard, as it is for nagfor and ifort. So, should this
> be closed now?
I still get an ICE:
pr55735.f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
Jürgen Reuter changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #4 from Jürgen Reuter ---
In the recent trunk (r264725) does _not_ give an ICE anymore, but the code is
vetoed as non-standard, as it is for nagfor and ifort. So, should this be
closed now?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #3 from Tobias Burnus 2012-12-18
20:04:12 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Postscript: The example in comment 0 mixes a scalar and an array pointers.
> > While the ICE occurs with either, the dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- C
15 matches
Mail list logo
