[Bug fortran/67802] New: ICE on initializing character with wrong len type

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With a wrong data type for len instead of a scalar-int-expr : $ cat za2.f90 program p character(1.) :: c1 = ' ' character(1d1) :: c2

[Bug fortran/67805] ICE on array constructor with wrong character specification

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67805 --- Comment #2 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- And these variants are silently accepted : $ cat z5.f90 program p print *, '1: ', [character(.true.) :: 'x', 'y'] print *, '2: ', [character(.false.)

[Bug fortran/67802] ICE on initializing character with wrong len type

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67802 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Whereas, without initialization relevant errors are detected : $ cat za1.f90 program p character(1.) :: c1 character(1d1) :: c2 character((0.,1.))

[Bug fortran/67804] ICE on data initialization of type(character) with wrong data

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Correct with a scalar string : $ cat z2.f90 program p type t character :: c end type type(t) :: x data x /t('1')/ print *, x end $ gf

[Bug fortran/67805] ICE on array constructor with wrong character specification

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67805 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- For these variants : $ cat z4.f90 program p print *, [character([.true.]) :: 'x', 'y'] print *, [character([.false.]) :: 'x', 'y'] print *, [cha

[Bug fortran/67806] New: ICE on initialization of type(character) with len null

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code : $ cat z1.f90 program p type t character(null()) :: c end type type(t) :: x = t('a') end yields : $ gfortran -g -O0 -Wall

[Bug fortran/67803] ICE on concatenating wrong character array constructor

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Whereas : $ cat z2.f90 program p character(2) :: x(1) x = '0' // [character :: '1'] print *, x end $ gfortran -g -O0 -Wall -fcheck=all -fno-fr

[Bug fortran/67803] New: ICE on concatenating wrong character array constructor

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With wrong data in a character array constructor : $ cat z1.f90 program p character(2) :: x(1) x = '0' // [character :: 1] x = '0

[Bug fortran/67779] Strange ordering with strings in extended object

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> changed: What|Removed |Added

[Bug fortran/67805] New: ICE on array constructor with wrong character specification

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code : $ cat z1.f90 program p print *, [character('') :: 'x', 'y'] end and this variation : $ cat z2.f90 program p

[Bug fortran/67806] ICE on initialization of type(character) with len null

2015-10-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67806 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Silently accepted without declaring x : $ cat z4b.f90 program p integer, pointer :: n type t character(null(n)) :: c end type end $ gfort

[Bug fortran/67614] ICE on using arithmetic if with null

2015-09-24 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 --- Comment #4 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- In general, a future extension to check pointer status looks promising (at compile time and runtime). With a tiny and simple source the problem is

[Bug fortran/67614] ICE on using arithmetic if with null

2015-09-24 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 --- Comment #5 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- For comparison, a logical if (assumes scalar-logical-expr instead of scalar-numeric-expr in arithmetic if) "avoids" an ICE. Analogous examples

[Bug fortran/67615] New: ICE on using arithmetic if with array instead of scalar

2015-09-17 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An arithmetic if with an array instead of a numeric scalar : program p integer :: z(1) = [1] if ( z ) 1, 2, 3 1

[Bug fortran/67615] ICE on using arithmetic if with array instead of scalar

2015-09-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- With an array constructor : $ cat z6.f90 program p if ( [1] ) 1, 2, 3 if ( [1, -1] ) 1, 2, 3 if ( [real :: 1, -1] ) 1, 2, 3 1 stop 1 2 stop 2

[Bug fortran/67614] ICE on using arithmetic if with null

2015-09-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- $ cat z4.f90 program p integer, pointer :: z => null() if ( z ) 1, 2, 3 1 stop 1 2 stop 2 3 stop 3 end $ gfortran -g -O0 -Wall -fcheck=all -fno

[Bug fortran/67616] ICE on data initialization of type variable in block

2015-09-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Compiles without block : program p type t end type type(t) :: x data x /t()/ end Compiles with block and intrinsic type : program p

[Bug fortran/67614] New: ICE on using arithmetic if with null

2015-09-17 Thread gerhard.steinmetz.fort...@t-online.de
Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Some cases with oldstyle arithmetic if in combination with null instead of a scalar-numeric-expr : $ cat z1.f90 program p integer, allocatable :: z if ( null(z

[Bug fortran/67616] New: ICE on data initialization of type variable in block

2015-09-17 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With an embedding block construct : $ cat z1.f90 program p type t end type block type(t) :: x data x /t()/ end block end

[Bug fortran/67542] New: ICE on initializing type variable with a longer array

2015-09-10 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This test case with a longer array in initializer of y : $ cat z1.f90 program p type t integer :: n character(8) :: c(1) end type

[Bug fortran/67542] ICE on initializing type variable with a longer array

2015-09-10 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- The ICE disappears if some prints are added : $ cat z2.f90 program p type t integer :: n character(8) :: c(1) end type type(t) :: x

[Bug fortran/67543] New: ICE on associate with improper association

2015-09-10 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This construct with an improper association with null ... subroutine s associate (x => null()) end associate end subroutine or this variat

[Bug fortran/67524] New: ICE on using implicit character instead of implicit none etc.

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: ---

[Bug fortran/67526] New: ICE on missing end parenthesis in substring construct

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A missing end parenthesis : program p character :: c1 = 'abc'(: character :: c2 = 'abc'(3: character :: c3 = 'abc'(:1

[Bug fortran/67526] ICE on missing end parenthesis in substring construct

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Whereas : $ cat y1.f90 program p character(3) :: z = 'abc' character :: c1 = z(3: end $ gfortran y1.f90 y1.f90:3:24: character :: c1

[Bug fortran/67524] ICE on using implicit character instead of implicit none etc.

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67524 --- Comment #2 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- There is no problem when implicit character(8) (a-z) is changed to one of implicit none implicit integer (a-z) implicit logical (a-z) im

[Bug fortran/67525] New: ICE on select type with improper selector

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This test case with an improper selector ... real function f(x) select type (x) end select end or this variation ... real function f(x

[Bug fortran/67524] ICE on using implicit character instead of implicit none etc.

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67524 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Here, all variables are declared explicitly, but using "implicit character" ... $ cat z1_imchfe.f90 module m implicit character(8) (a-z) cont

[Bug fortran/67525] ICE on select type with improper selector

2015-09-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67525 --- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fort...@t-online.de> --- Whereas : $ cat y1.f90 subroutine f(x) select type (x) end select end $ gfortran -c y1.f90 y1.f90:2:18: select type (x) 1

[Bug fortran/66724] ICE on input/output statements with wrong specifier data

2015-07-06 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Longer scheme : backspace (1, iomsg=#) close (1, iomsg=#) close (1, status=#) endfile (1, iomsg=#) flush (1, iomsg=#) inquire (1, iomsg=#) open

[Bug fortran/66725] Issue with silent conversion int to char, ICE if int too large

2015-07-02 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66725 --- Comment #2 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- A more extensive list of different cases : close (1, status=257) open (1, access=257) open (1, action=257) open (1, asynchronous=257) open (1, blank

[Bug fortran/66725] Issue with silent conversion int to char, struggling in gfc_widechar_to_char

2015-07-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66725 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Whereas : $ cat y_test_char_1.f90 program p print *, char(100) end $ gfortran y_test_char_1.f90 $ a.out d --- $ cat y_test_char_2.f90 program p print

[Bug fortran/66724] New: ICE on input/output statements with wrong specifier data

2015-07-01 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- For most input/output statements and for several specifiers compilation aborts if assigned specifier key is not changeable

[Bug fortran/66725] New: Issue with silent conversion int to char, struggling in gfc_widechar_to_char

2015-07-01 Thread gerhard.steinmetz.fort...@t-online.de
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Sometimes a silent conversion from integer to character occurs where it should not IMO, but should give

[Bug fortran/66708] New: Possible (minor) improvement on formatted io with format too short

2015-06-30 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Formatted read or write of a variable (list) needs a format (fmt) string longer than 2 characters, because

[Bug fortran/66708] Possible (minor) improvement on formatted io with format too short

2015-06-30 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66708 Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de changed: What|Removed |Added Severity|normal

[Bug fortran/66709] New: ICE on formatted io with parameter array specifier fmt

2015-06-30 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Specifying a character array for fmt is legal fortran. If declared as parameter, compilation fails : $ cat z_wr_fmt_ice_1.f90 program p character(4

[Bug fortran/66707] New: Endless compilation on wrong usage of common

2015-06-30 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- After printing some correct and helpful error messages, compilation of the following snippets (wrong code) will not end. Tested with gfortran 5.1.1, 4.9.0, 4.8.3

[Bug fortran/66575] Endless compilation on missing end interface

2015-06-30 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66575 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Playing around, I've found other cases (wrong code with procedure) causing endless compilation on my environment, e.g. $ cat zlctp_1.f90 program p procedure(g

[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt

2015-06-30 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66709 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Whereas versions without parameter compile and run fine : $ cat z_wr_fmt_ice_4.f90 program p character(4) :: fmt(1) = '(i8)' integer :: n read (*, fmt=fmt

[Bug fortran/66643] New: Missing compilation error for formatted data transfer without format

2015-06-23 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- For read/write an io-unit that is an asterisk (*) identifies an external unit that is preconnected for sequential

[Bug fortran/66643] Missing compilation error for formatted data transfer without format

2015-06-23 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66643 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Minimalistic code : $ cat z_write_none.f90 program p write (*) end $ gfortran -g -O0 -Wall -fcheck=all z_write_none.f90 $ a.out At line 2 of file

[Bug fortran/66056] Segmentation fault for lonely label in type

2015-06-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056 --- Comment #2 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Hmm, there is always an ICE on my environment, for any used options.

[Bug fortran/66056] Segmentation fault for lonely label in type

2015-06-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- The following test file generates an endless compilation for every subroutine. It's worth looking deeper. $ cat type_with_lonely_numbers.f90 program p call s1

[Bug fortran/66056] Segmentation fault for lonely label in type

2015-06-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056 --- Comment #4 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- These two do not circle around, $ cat y1.f90 program p type t integer :: n = 1 1 ! 2 ! end type type(t) :: a print *, a end $ cat

[Bug fortran/66575] New: Endless compilation on missing end interface

2015-06-17 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- If the first end interface is missing : $ cat zlcti_1.f90 module m interface operator (.f.) procedure f !end interface interface

[Bug fortran/66575] Endless compilation on missing end interface

2015-06-17 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66575 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- The above sources can be reduced further. The part below contains (inclusive contains) is not needed to produce the effect : $ cat zlcti_4.f90 module m

[Bug fortran/66244] ICE on assigning a value to a pointer variable

2015-06-15 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66244 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Perhaps it's better to make the target array a bit larger. And to provide a not so minimalistic version : program p integer, target :: a(4) integer

[Bug fortran/66544] ICE on function with pointer result in combination with implicit none

2015-06-15 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Originally not the above z0.f90, but this code was thought as test case : $ cat z0.f90 module m contains function f() result(z) procedure(f

[Bug fortran/66545] ICE on using undefined parameter/variable values

2015-06-15 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66545 --- Comment #2 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- FYI, it's astonishing, but this code compiles without an ICE and prints some reasonable error messages : $ cat z2_type.f90 program p type t integer :: n

[Bug fortran/66544] New: ICE on function with pointer result in combination with implicit none

2015-06-15 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code with implicit none : module m implicit none contains function f() result(z

[Bug fortran/66545] ICE on using undefined parameter/variable values

2015-06-15 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66545 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Trivially, the following cases behave similar : $ cat z1_real.f90 program p real, parameter :: c1 = (c1) real, parameter :: c2 = c2 real :: c3 = (c3

[Bug fortran/66545] New: ICE on using undefined parameter/variable values

2015-06-15 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code uses parameter/variable values before they are defined/initialized. $ cat z1_complex.f90 program p complex, parameter :: c1 = (c1

[Bug fortran/66493] ICE on alternate return argument for typebound procedure

2015-06-11 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66493 --- Comment #7 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Interestingly, there are some tests in the test suite already, especially altreturn_3.f90 and altreturn_8.f90. The latter is using a nopass attribute and compiles

[Bug fortran/66493] ICE on alternate return argument for typebound procedure

2015-06-11 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66493 --- Comment #8 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Case zarc1_2_pass.f90 should be definitely illegal code.

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-06-10 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #15 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35745 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35745action=edit test case pr66193_3_diverse_new.f90 Better test, replaces

[Bug fortran/66494] New: ICE on using same name for embedded subroutine

2015-06-10 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This ambiguous code ... recursive subroutine s call s contains subroutine s end end yields (with gfortran 5.1.1, 4.9.0, 4.8.3

[Bug fortran/66493] New: ICE on alternate return argument for typebound procedure

2015-06-10 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code with an alternate return argument (*) seems to be improper : module p type t contains procedure

[Bug fortran/66495] New: [5 Regression] Issue with same name for embedded function

2015-06-10 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Another test case : integer function f() contains integer function f() end end yields (gfortran 5.1.1

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-06-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #14 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Attached some prepared test files. Added more test cases for integer and real. Added new test case for logical : subroutine s2 logical(8), parameter :: z1(2

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-06-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #13 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35728 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35728action=edit test case pr66193_3_diverse.f90

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-06-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #12 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35727 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35727action=edit test case pr66193_2_integer.f90

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-06-09 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #11 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35726 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35726action=edit test case pr66193_1_real.f90

[Bug fortran/66461] New: ICE on missing end program in fixed source

2015-06-08 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- A missing end program in a fixed source s.f : program p integer x(2) x = 0 if ( x(1) 0 .or. x(2) 0 ) print *, x

[Bug fortran/66380] New: ICE for intrinsic reshape with insufficient number of array elements

2015-06-02 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code with less array elements than requested via shape sh : program p integer, parameter :: sh(2) = [2

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

2015-05-28 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- I do agree, that some extra temporary data is necessary and there should be a practical (high) limit for something like that. Let the helper buffers be five or ten

[Bug fortran/66310] New: Problems with intrinsic repeat for large number of copies

2015-05-27 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This small program compiles without any message (gfortran 5.1.1, 4.9.0, 4.8.3) program p character :: z = 'z

[Bug fortran/66311] [5 Regression] Problems with some integer(16) values

2015-05-27 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Of course, some computations are wrong, too. For example : program p integer(8), parameter :: z = huge(1_8) print *, 2_16 * z print *, 2 * int

[Bug fortran/66311] New: [5 Regression] Problems with some integer(16) values

2015-05-27 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- First of all, it's great to support integer(16). But printing some numbers from range 2^63 to 2^64-1 with this snippet : program p print

[Bug fortran/66245] New: ICE on select type with empty type spec

2015-05-21 Thread gerhard.steinmetz.fort...@t-online.de
Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This test case with an empty type selector (type is) ... program p type t; end type class(t), allocatable :: x call s contains subroutine

[Bug fortran/66244] New: ICE in lhd_set_decl_assembler_name

2015-05-21 Thread gerhard.steinmetz.fort...@t-online.de
Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code snippet ... program p integer, target :: a(3) integer, pointer :: z = a(3) z = 0 print *, z end yields (with gfortran 5.1.1 on SUSE

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-05-20 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #10 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Perhaps it's better to make one factor larger. Maybe the following will help. $ cat zz1.f90 program p real :: z(2) z = 10 + [real :: 1, 2

[Bug fortran/66193] New: ICE for initialisation of some non-zero-sized arrays

2015-05-18 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This initialisation of an array (NOT zero sized, NOT a parameter) program p real :: z(2) z = 1 + [real :: 1, 2] end yields

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-05-18 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- For integer instead of real ... program p integer :: z(2) z = 1.2 + [integer :: 3.5, 4.5] print *, z end it compiles with gfortran

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

2015-05-18 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Hmm, no observable difference with option -fno-frontend-optimize, sorry. Of course I probed some combinations for several options. One example for a more extensive

[Bug fortran/66128] New: ICE for some intrinsics with zero sized array parameter

2015-05-12 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This simplified code snippet with a zero sized array parameter z ... program p integer, parameter :: z(0) = 0 print

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

2015-05-12 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66128 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Some more examples with other error messages. This one ... program p integer, parameter :: z(0) = 0 print *, count(z 0) end yields : internal

[Bug fortran/66107] New: ICE on missing parameter value for initialisation (segfault)

2015-05-11 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code snippet with a missing parameter value for n ... program p character(*), parameter :: z(2) = [character(n

[Bug fortran/66106] New: ICE on incomplete interface operator block (gfc_op2string)

2015-05-11 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code snippet with an incomplete interface operator block ... program p interface operator ( .gt. ) end

[Bug fortran/66043] New: ICE on storage_size of null or output of null array

2015-05-07 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- --- code snippet 1 : program p print *, storage_size([null()]) end f951: internal compiler error: Invalid expression in gfc_element_size

[Bug fortran/66044] New: ICE on misplaced entry statement

2015-05-07 Thread gerhard.steinmetz.fort...@t-online.de
Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Some code snippets : --- entry e; end --- subroutine p end entry e end --- program p type t contains entry e end type end

[Bug fortran/66045] New: ICE on incorrect code with null

2015-05-07 Thread gerhard.steinmetz.fort...@t-online.de
Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This incorrect code snippet disrupts : program p contains integer :: null=null() end f951: internal compiler error: Segmentation fault Tested

[Bug fortran/66052] New: Segmentation fault for misplaced protected statement

2015-05-07 Thread gerhard.steinmetz.fort...@t-online.de
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code fragment with interchanged lines module p contains protected x end produces (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) f951

[Bug fortran/66056] New: Segmentation fault for lonely label in type

2015-05-07 Thread gerhard.steinmetz.fort...@t-online.de
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code fragment with a lonely label in a type ... program p type t 1 ! end type end or this variation ... program p type t

[Bug fortran/66057] New: ICE for incomplete generic statement (gfc_match_generic)

2015-05-07 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code fragment with an incomplete generic statement ... program p type t contains generic

[Bug fortran/66040] New: ICE on misplaced sequence in function

2015-05-06 Thread gerhard.steinmetz.fort...@t-online.de
Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An ICE occurs with a misplaced sequence in a function. $ cat disrupt_2_sequence.f90 real function f(x) sequence end $ gfortran -c disrupt_2_sequence.f90

[Bug fortran/66040] ICE on misplaced sequence in function

2015-05-06 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- There are more cases for ICEs on misplaced statements in a function. For example : --- real function f() block data end --- real function f

[Bug fortran/66039] New: ICE on incomplete parentheses at rewind, flush, endfile, backspace

2015-05-06 Thread gerhard.steinmetz.fort...@t-online.de
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Created attachment 35483 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35483action=edit more code variants

<    1   2   3   4   5   6