[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Zecca  ---
Still in current trunk.

The compilers NAG nagfor and Intel ifort correctly detect a syntax error.

nagfor -S -w gfbug43.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug43.f, line 12: Scalar value for array pointer component P of type T
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S -w gfbug43.f
gfbug43.f(12): error #6594: The rank of a component in a structure constructor
differs from the rank of the component of the derived type.   [F]
  u=t(f())
--^
compilation aborted for gfbug43.f (code 1)

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
1) Sometimes error reports slip through the cracks, it happened to me,
and I found it's good
to remind that the bug is still around. Sometimes it happened the
contrary, the bug silently
disappears but the error report is still open.
There are more things in heaven and earth, Horatio, Than are
dreamt of in your philosophy.

2)  At least I got an answer from you, that an error would be better
than an ICE,
 this is obvious to me but not to everybody, it also influences
the credibility
 of a product, a crashing product is less credible than a product
issuing error messages.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> This is still in trunk 249883

Did you fixed it? If no, the only relevant information would be to report that
it has been fixed.

> The test case may be wrong, but
>
> 1) gfortran should never crash but deliver an error message instead
>
> 2) on this test case gfortran is giving no error message
>   so how do I know it is wrong?

Although it happens that compilers ICE on valid codes, most of the time ICEs
are the signature of invalid codes. Indeed an error would be better than an
ICE.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.8.0   |8.0

--- Comment #6 from Vittorio Zecca  ---
This is still in trunk 249883

The test case may be wrong, but

1) gfortran should never crash but deliver an error message instead

2) on this test case gfortran is giving no error message
   so how do I know it is wrong?

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
ICE still in 7.1.0 and trunk 8.0.0

Even if the code is invalid the compiler should not just crash.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
ICE on gfortran 5.3.0

gfortran should never have an ICE, even on invalid code.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
ICE on invalid code.  Adding 

 real, dimension(:) :: f

in the interface makes the code compile.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
! gfortran ICE in gfc_conv_expr_descriptor at fortran/trans-array.c
  interface
   function f()
   pointer f
   end
  end interface
  type t
  real,pointer ::  p(:)
  end type
  type(t) u
  u=t(f())
  end


gfortran gfbug43.f
gfbug43.f:12:0:

   u=t(f())
 1
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6534
0x6b5b60 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc-5.2.0/gcc/fortran/trans-array.c:6534
0x6d513b gfc_trans_subcomponent_assign
../../gcc-5.2.0/gcc/fortran/trans-expr.c:6802
0x6d4b3b gfc_trans_structure_assign
../../gcc-5.2.0/gcc/fortran/trans-expr.c:7036
0x6d6084 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-5.2.0/gcc/fortran/trans-expr.c:7065
0x6d7060 gfc_trans_assignment_1
../../gcc-5.2.0/gcc/fortran/trans-expr.c:8947
0x6a4545 trans_code
../../gcc-5.2.0/gcc/fortran/trans.c:1665
0x6c3e83 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.2.0/gcc/fortran/trans-decl.c:5841
0x662270 translate_all_program_units
../../gcc-5.2.0/gcc/fortran/parse.c:5340
0x662270 gfc_parse_file()
../../gcc-5.2.0/gcc/fortran/parse.c:5537
0x6a1695 gfc_be_parse_file
../../gcc-5.2.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402



Vittorio Zecca zeccav at gmail dot com changed:



   What|Removed |Added



Version|4.7.0   |4.8.0



--- Comment #1 from Vittorio Zecca zeccav at gmail dot com 2013-04-16 
08:51:27 UTC ---

I still have the same bug on gfortran 4.8.0.

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[Joost.VandeVondele at pci dot uzh.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402

Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-09-15
 Ever Confirmed|0   |1