Bug 78122 - [5/6/7/8 Regression] [F08] ICE in get, at cgraph.h:395
Summary: [5/6/7/8 Regression] [F08] ICE in get, at cgraph.h:395
Status: RESOLVED DUPLICATE of bug 55207
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 7.0
: P4 normal
Target Milestone: 5.5
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2016-10-26 22:15 UTC by physiker
Modified: 2023-03-18 17:40 UTC (History)
2 users (show)

See Also:
Host: x86_64-apple-darwin13.4.0, x86_64-linux-gnu
Target: x86_64-apple-darwin13.4.0
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-10-27 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description physiker 2016-10-26 22:15:48 UTC
Compiling the file pi.f90 causes an internal compiler error in get, at cgraph.h:395. When the program-name pi (after the program statement) is replaced by p, the code compiles without triggering an ice (see below).   

pi.f90
program pi
    implicit none

    real, target  :: a
    real, pointer :: p => a

    a = 1.

    write(*, *)  'a:', a
    write(*, *)  'p:', p

end program pi


LANG=C gfortran-7 -o pi pi.f90 -W -Wall -v
Driving: gfortran-7 -o pi pi.f90 -W -Wall -v -mmacosx-version-min=10.9.4 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/7.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-7
Thread model: posix
gcc version 7.0.0 20161025 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'pi' '-Wextra' '-Wall' '-v' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/7.0.0/f951 pi.f90 -fPIC -quiet -dumpbase pi.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase pi -Wextra -Wall -version -fintrinsic-modules-path /usr/local/lib/gcc/x86_64-apple-darwin13.4.0/7.0.0/finclude -o /var/folders/97/4qnhjhtn25s86s9hkz0h37_m0000gn/T//ccA3BI7y.s
GNU Fortran (GCC) version 7.0.0 20161025 (experimental) (x86_64-apple-darwin13.4.0)
	compiled by GNU C version 7.0.0 20161025 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 7.0.0 20161025 (experimental) (x86_64-apple-darwin13.4.0)
	compiled by GNU C version 7.0.0 20161025 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
f951: internal compiler error: in get, at cgraph.h:395

f951: internal compiler error: Abort trap: 6
gfortran-7: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

s/pi/p

LANG=C gfortran-7 -o pi pi.f90 -W -Wall 
pi.f90:5:22:

     real, pointer :: p => a
                      1
Error: Symbol 'p' at (1) cannot have a type
pi.f90:10:24:

     write(*, *)  'p:', p
                        1
Error: Symbol at (1) is not appropriate for an expression
Comment 1 Martin Liška 2016-10-27 07:19:05 UTC
Confirmed, started with 4.8.0. I'll take a look at that.
Comment 2 Martin Liška 2016-11-03 15:05:39 UTC
Not being a fortran expert, however ifort rejects the source code:

/tmp/pi.f90(5): error #6592: This symbol must be a defined parameter, an enumerator, or an argument of an inquiry function that evaluates to a compile-time constant.   [A]
    real, pointer :: p => a
--------------------------^
/tmp/pi.f90(5): error #6973: This is not a valid initialization expression.   [A]
    real, pointer :: p => a
--------------------------^

Problem is that symtab_node::get is called for a local symbol.
Comment 3 physiker 2016-11-03 17:24:48 UTC
(In reply to Martin Liška from comment #2)
> Not being a fortran expert, however ifort rejects the source code:
> 
> /tmp/pi.f90(5): error #6592: This symbol must be a defined parameter, an
> enumerator, or an argument of an inquiry function that evaluates to a
> compile-time constant.   [A]
>     real, pointer :: p => a
> --------------------------^
> /tmp/pi.f90(5): error #6973: This is not a valid initialization expression. 
> [A]
>     real, pointer :: p => a
> --------------------------^
> 
> Problem is that symtab_node::get is called for a local symbol.

Ifort version 17 (linux) compiles pi.f90.
ifort -o pi pi.f90 -warn all -check all 
 ./pi
 a:   1.000000    
 p:  0.0000000E+00
 T
ifort -v
ifort version 17.0.0
Comment 4 Martin Liška 2016-11-04 09:05:49 UTC
Ok, problem is that Fortran FE decides to make p STATIC in:

  /* 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
     are SAVE_NONE but have an initializer.  Otherwise explicitly
     initialized variables are SAVE_IMPLICIT and explicitly saved are
     SAVE_EXPLICIT.  */
  if (!sym->attr.use_assoc
	&& (sym->attr.save != SAVE_NONE || sym->attr.data
	    || (sym->value && sym->ns->proc_name->attr.is_main_program)
	    || (flag_coarray == GFC_FCOARRAY_LIB
		&& sym->attr.codimension && !sym->attr.allocatable)))
    TREE_STATIC (decl) = 1;

and thus call graph is unhappy as there's a reference between a varpool symbol and a local variable. I quess it must be fixed in the FE.
Comment 5 janus 2016-11-07 20:25:21 UTC
I think the test case is valid. A workaround for the ICE is to declare 'a' with  the SAVE attribute.

According to the F08 standard every variable in the main program implicitly gets the SAVE attribute, which is the subject of PR55207.

I assume the regression is caused by r208668.
Comment 6 Dominique d'Humieres 2017-07-02 09:08:54 UTC
> According to the F08 standard every variable in the main program implicitly
> gets the SAVE attribute, which is the subject of PR55207.

Marked as duplicate of PR55207.

*** This bug has been marked as a duplicate of bug 55207 ***