[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2025-06-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.4|13.5

--- Comment #8 from Jakub Jelinek  ---
GCC 13.4 is being released, retargeting bugs to GCC 13.5.

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2024-05-21 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.3|13.4

--- Comment #7 from Jakub Jelinek  ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2023-07-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.2|13.3

--- Comment #6 from Richard Biener  ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2023-04-25 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #5 from Richard Biener  ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2023-02-13 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> Patch attached.

The patch fixes comment#0, but not e.g. this slight variation:

  if ( len([character(n+1) :: '']) /= 0 ) stop

valgrind produces long output ... :-(

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2022-04-05 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-04-05
 Ever confirmed|0   |1
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch attached.

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2022-04-05 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

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 ---
Created attachment 52752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52752&action=edit
Patch to fix PR

The problem is two-fold.  First, there is the infamous NULL pointer
dereference in resolve.cc(resolve_variable).  Second, if the variable
'n' is implicitly defined and it is in a PROGRAM or MODULE specification
part of the scoping unit, it cannot be a variable.

[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298

2022-04-05 Thread gscfq--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---


Interestingly, this type-spec "character(n)" with undefined "n"
is simply ignored in following test case :


$ cat z7.f90
program p
   print *, len([character(n) :: ''])
   print *, len([character(n) :: '1'])
   print *, len([character(n) :: '12'])
   print *, len([character(n) :: '123'])
   print *, len([character(n) :: '123456789'])
   print *, len([character(n) :: '1234567890123456789'])
end


$ gfortran-12-20220403 z7.f90 && ./a.out
   0
   1
   2
   3
   9
  19