[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #4 from Kris  ---
Created attachment 47653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47653&action=edit
preprocessed source file

gzipped preprocessed source file attached

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #2 from Kris  ---
It builds with -O2, fails with -O3.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #1 from Kris  ---
sorry. I guess I should add this version of gcc is built from the git version
pulled this morning.

gcc (GCC) 10.0.0 20200114 (experimental)

[Bug c/93268] New: ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

Bug ID: 93268
   Summary: ICE with gcc-10 when compiling hypre library with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristopher.kuhlman at gmail dot com
  Target Milestone: ---

I am building petsc, and the hypre library being built as part of that triggers
this ICE when using optimization. When building the same library with -Og there
is no ICE.

This library didn't trigger this ICE with a gcc version from a month or two
ago, so this is maybe due to a recent change?

I created a pre-processed version of the relevant source file, but it is
enormous (12k lines). I can attach it if desired.

Kris

--

/home/klkuhlm/src/petsc/tgcc-c-perf/bin/mpicc -fstack-protector -O3
-march=native  -DHAVE_CONFIG_H -I.. -I. -I./.. -I./../blas -I./../lapack
-I./../utilities -I./../seq_mv  -I/home/klkuhlm/src/petsc/tgcc-c-perf/include
-c par_csr_matop_marked.c 
../config/Makefile.config:49: recipe for target 'par_csr_matop.o' failed
make[1]: Leaving directory
'/home/klkuhlm/src/petsc/tgcc-c-perf/externalpackages/hypre-2.15.1/src/parcsr_mv'
Makefile:90: recipe for target 'all' failedduring GIMPLE pass: vect
par_csr_matop.c: In function ‘hypre_ParCSRMatrixExtractBExt_Arrays_Overlap’:
par_csr_matop.c:1063:6: internal compiler error: in get_load_store_type, at
tree-vect-stmts.c:2462
 1063 | void hypre_ParCSRMatrixExtractBExt_Arrays_Overlap(
  |  ^~~~
0x6f7de9 get_load_store_type
../../gcc-trunk/gcc/tree-vect-stmts.c:2462
0xfb254b vectorizable_load
../../gcc-trunk/gcc/tree-vect-stmts.c:8708
0xfc8f0e vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:10989
0xfcac1e vect_transform_loop_stmt
../../gcc-trunk/gcc/tree-vect-loop.c:8299
0xfe1c6c vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:8690
0xffd6f9 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:989
0xffd8f7 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:1026
0xffe3f9 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:1125
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[1]: *** [par_csr_matop.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 1

[Bug fortran/91003] New: ICE when compiling LAPACK (CGEGV) with optimization

[kristopher.kuhlman at gmail dot com]

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

Bug ID: 91003
   Summary: ICE when compiling LAPACK (CGEGV) with optimization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristopher.kuhlman at gmail dot com
  Target Milestone: ---

Latest version of gfortran gives error and ICE when compiling CGEGV from LAPACK
using the following command line (from petsc build). 

home/klkuhlm/src/petsc/tgcc-c-perf/bin/mpif90 -c -Wall -ffree-line-length-0
-Wno-unused-dummy-argument -Ofast -march=native 

This same thing worked with the trunk version of the compiler from a month or
so ago.  It also works with this same compiler without optimizations turned on.

Kris

--

cgegv.f:282:0:

  282 |   SUBROUTINE CGEGV( JOBVL, JOBVR, N, A, LDA, B, LDB, ALPHA, BETA,
  | 
Error: type mismatch in ‘vec_cond_expr’
vector(8) unsigned int
vector(8) 
vector(8) 
vect_ilimit_186.167_852 = VEC_COND_EXPR ;
cgegv.f:282:0: Error: type mismatch in ‘vec_cond_expr’
vector(8) unsigned int
vector(8) 
vector(8) 
vect_ilimit_186.167_853 = VEC_COND_EXPR ;
during GIMPLE pass: vect
cgegv.f:282:0: internal compiler error: verify_gimple failed
0xe3bcd1 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5426
0xd19cbf execute_function_todo
../../gcc-trunk/gcc/passes.c:1963
0xd1abee execute_todo
../../gcc-trunk/gcc/passes.c:2017
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[kristopher.kuhlman at gmail dot com]

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

--- Comment #10 from Kris  ---
that fixed the problem for me. thanks!

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[kristopher.kuhlman at gmail dot com]

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

--- Comment #7 from Kris  ---
Created attachment 46522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46522&action=edit
petsc source file that ICE happens on

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[kristopher.kuhlman at gmail dot com]

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

Kris  changed:

   What|Removed |Added

 CC||kristopher.kuhlman at gmail 
dot co
   ||m

--- Comment #6 from Kris  ---
I now get this same internal compiler error when I build petsc
(https://www.mcs.anl.gov/petsc/), using a configuration that works with version
7.4 of gcc.

  FC tgcc-c-debug/obj/sys/f90-mod/petscsysmod.o
f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
0x1798897 deps_add_target(mkdeps*, char const*, int)
../../gcc-trunk/libcpp/mkdeps.c:241
0x1798897 deps_add_target(mkdeps*, char const*, int)
../../gcc-trunk/libcpp/mkdeps.c:236
0x868d5f dump_module
../../gcc-trunk/gcc/fortran/module.c:6227
0x868f30 gfc_dump_module(char const*, int)
../../gcc-trunk/gcc/fortran/module.c:6302
0x88131e gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6284
0x8ca48f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
gmakefile:164: recipe for target 'tgcc-c-debug/obj/sys/f90-mod/petscsysmod.o'
failed

[Bug fortran/70350] [5 Regression] ICE with -fcheck=all and array initialization

[kristopher.kuhlman at gmail dot com]

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

--- Comment #10 from Kris  ---
Thank you for the effort.

On Thursday, June 2, 2016, pault at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70350
>
> Paul Thomas  changed:
>
>What|Removed |Added
>
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |FIXED
>
> --- Comment #9 from Paul Thomas  ---
> I have backported the fix from trunk/6-branch. I didn't add a testcase
> since
> The probability of any further changes causing a regression is zero.
>
> Thanks for the report. I am sorry that this has caused some inconvenience.
> However, as a volunteer, sometimes life outside gfortran intervenes, as it
> did
> here.
>
> Paul
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/70350] [5 Regression] ICE with -fcheck=all and array initialization

[kristopher.kuhlman at gmail dot com]

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

Kris  changed:

   What|Removed |Added

 CC||kristopher.kuhlman at gmail 
dot co
   ||m

--- Comment #7 from Kris  ---
I can confirm this problem, but I didn't upload my similar 13-line test case.
Will a fix for this make it into 5.3.1 eventually?

It is a real bummer that --fcheck=all crashes gfortran on Ubuntu 16.04 LTS,
which will be supported for nearly 5 more years. 

gfortran --version
GNU Fortran (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413

[Bug fortran/67674] New: Incorrect result or ICE for deferred-length character component

[kristopher.kuhlman at gmail dot com]

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

Bug ID: 67674
   Summary: Incorrect result or ICE for deferred-length character
component
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristopher.kuhlman at gmail dot com
  Target Milestone: ---

Created attachment 36368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36368&action=edit
test program

The attached test case results in incorrect results from trunk version of
gfortran (6.0). The same program gives a "not yet supported" message from 4.8.4
and gives an internal compiler error for 4.9.3. Using Ubuntu 14.04. Intel
compiler (15.03) gives expected results.

Maybe related to bug 50221?

1) Expected results (Intel compiler)
-
 length main program before   0
 length intermediate before   0
 length inner before   0
 length inner after  28
 here the word is finally set
 length intermediate after  28
 here the word is finally set
 length main program after  28
 final result:here the word is finally set


2) Trunk gfortran output (compiled will -Wall -Wextra)
--
 length main program before   0
 length intermediate before   0
 length inner before   0
 length inner after  28
 here the word is finally set
 length intermediate after  28
 here the word is finally set
 length main program after   0
 final result:


3) Gfortran 4.9.3 output 

test_allocatable_string.f90: In function ‘test’:
test_allocatable_string.f90:10:0: internal compiler error: in gimplify_expr, at
gimplify.c:8538
   allocate(character(len=0) :: my_string_type%name)
 ^
0x7c5472 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.3/gcc/gimplify.c:8538
0x7ca719 gimplify_modify_expr
../../gcc-4.9.3/gcc/gimplify.c:4510
0x7c3c31 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.3/gcc/gimplify.c:7627
0x7c66f6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.3/gcc/gimplify.c:5373
0x7c4b0b gimplify_statement_list
../../gcc-4.9.3/gcc/gimplify.c:1432
0x7c4b0b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.3/gcc/gimplify.c:8042
0x7c66f6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.3/gcc/gimplify.c:5373
0x7c3b5c gimplify_and_add
../../gcc-4.9.3/gcc/gimplify.c:385
0x7c3b5c gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.3/gcc/gimplify.c:7964
0x7c66f6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.3/gcc/gimplify.c:5373
0x7c6f96 gimplify_bind_expr
../../gcc-4.9.3/gcc/gimplify.c:1099
0x7c3a2a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.3/gcc/gimplify.c:7824
0x7c66f6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.3/gcc/gimplify.c:5373
0x7c763a gimplify_body(tree_node*, bool)
../../gcc-4.9.3/gcc/gimplify.c:8734
0x7c7987 gimplify_function_tree(tree_node*)
../../gcc-4.9.3/gcc/gimplify.c:8887
0x6c4877 cgraph_analyze_function(cgraph_node*)
../../gcc-4.9.3/gcc/cgraphunit.c:648
0x6c56b7 analyze_functions
../../gcc-4.9.3/gcc/cgraphunit.c:1016
0x6c6415 finalize_compilation_unit()
../../gcc-4.9.3/gcc/cgraphunit.c:2328
0x82f844 write_global_declarations()
../../gcc-4.9.3/gcc/langhooks.c:323
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #35 from Kris  2011-06-20 
02:31:45 UTC ---
(In reply to comment #34)
> Thanks, Janus -- you rock!

I concur.  Thanks!

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #31 from Kris  2011-06-08 
13:49:21 UTC ---
(In reply to comment #30)
> (In reply to comment #29)
> > Will this fix be applied to 4.6 or 4.5?

> However, if your life depends on it, we could maybe consider having an
> exception from that rule and doing a backport to the 4.6 branch (which is 
> still
> young), given that the patch is relatively small and simple.

Although my *life* does not depend on it, I think backporting this fix to 4.6
would be beneficial, because it will be a while before 4.7 will be released and
used widely.  

It seems to me that these sort of fixes are required before people will start
using the more modern features of Fortran03/gfortran.

Thanks for fixing this, regardless.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #29 from Kris  2011-06-08 
13:12:59 UTC ---
(In reply to comment #27)
> r174416 fixes all the test cases in this PR (except comment #11, which is
> invalid). I'm glad we finally nailed this one.
> 
> Closing as fixed. Thanks for reporting, Rich!

Will this fix be applied to 4.6 or 4.5?

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #15 from Kris  2011-05-27 
03:33:15 UTC ---
(In reply to comment #14)
> *) The error is triggered by USEing a module in which a 'bad' procedure is
> defined. 
> *) A 'bad' procedure is one having
>   b) a dummy argument 'foo' which is an extended derived type
>   a) another dummy argument 'bar', whose dimension(s) depends on a component 
> of
> 'foo'

I had this bug, but it went away when I verbatim copied the procedure I was
USEing and removed the USE statement (not optimal, but ok).  I still have lots
of other extended types and no other problems with gfortran -- based on my
limited experience, whatever triggers this bug is pretty subtle.

[Bug fortran/47720] problems with makefile dependency generation using -M

[kristopher.kuhlman at gmail dot com]

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

--- Comment #3 from Kris  2011-05-25 
19:45:15 UTC ---
(In reply to comment #2)
> I was using a build of gfortran from CVS 2/12/2011.

I meant SVN, not CVS.

[Bug fortran/47720] problems with makefile dependency generation using -M

[kristopher.kuhlman at gmail dot com]

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

--- Comment #2 from Kris  2011-05-25 
19:36:48 UTC ---
(In reply to comment #1)
> May I ask what version of gfortran this is? (Trunk build of gfortran from
> yesterday is a bit ambiguous) 

I was using a build of gfortran from CVS 2/12/2011.

> The reason I ask is that I am not getting as far as you. on gfortran 4.6.0 if
> have a program which uses two modules and dependency listing I get is 
> myprog.0:
> myprog.f90 which is less than helpful.

Using a more recent trunk build (sometime last week), I still get what I
originally posted.

$ gfortran-4.7 -cpp -M makegen?.f90
makegen1.o constants.mod: makegen1.f90
makegen2.o utility.mod: makegen2.f90 constants.mod constants.mod \
 constants.mod

If it is considered to be ok that there is all this duplication, then I guess I
don't have a problem.  Maybe the documentation for this feature could be
cleared up to mention this too?

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #11 from Kris  2011-04-04 
13:33:17 UTC ---
(In reply to comment #10)
> *** Bug 48428 has been marked as a duplicate of this bug. ***

I further reduced the code from bug 48248.  I don't know if this helps, but if
you change the size of the a2n vector from something that refers to a component
of e to an integer, it goes away.

--

mio_component_ref_error.f90:39.41:

use elliptical_elements, only : line 
 1
Internal Error at (1):
mio_component_ref(): Component not found

--

module type_definitions
  implicit none
  private 
  public ::   ellipse 

  type :: matching 
 integer :: n = -999
  end type matching

  type, extends(matching) :: ellipse
  end type ellipse

end module type_definitions

module elliptical_elements
  implicit none
contains
  function line(e) result(a2n)
use type_definitions, only : ellipse

type(ellipse), intent(in) :: e
complex(8), dimension(e%N) :: a2n   ! <- change "e%N" to "10" 
  end function line
end module elliptical_elements

module solution_mod
  implicit none
  private
  public :: matrix_solution
contains
  subroutine matrix_solution(e) 
use type_definitions, only :  ellipse
use elliptical_elements, only : line 
type(ellipse), intent(inout) :: e
e = line(e)
  end subroutine matrix_solution
end module solution_mod

[Bug fortran/48428] New: gfortran internal error

[kristopher.kuhlman at gmail dot com]

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

   Summary: gfortran internal error
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kristopher.kuhl...@gmail.com


Created attachment 23864
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23864
reduced program fortran code that triggers the internal error

I have reduced a fortran program to the attached test case that triggers the
following internal error:

$ gfortran mio_component_ref_error.f90
mio_component_ref_error.f90:45.41:

use elliptical_elements, only : line 
 1
Internal Error at (1):
mio_component_ref(): Component not found

This happens using gfortran 4.5.1, 4.6.0, and the trunk build from yesterday
(4.7).  

The error goes away if you copy the line() function from the
elliptical_elements module into the the solution_mod module and comment out the
use statement on line 45.

Maybe this bug is related to bug 47601?  I am experiencing this problem in
64-bit Ubuntu Linux.

--

I don't know if the following tidbit helps, but while I was cutting the program
down to this test case, I briefly experienced the following different error at
the same location when I eliminated some of the extends() dependencies of one
type on another in the type_definitions module.  I can't seem to reproduce this
different error anymore, though.

gfortran -c  -o solution.o solution.f90
solution.f90:10.41:

use elliptical_elements, only : line 
 1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

[Bug fortran/47720] New: problems with makefile dependency generation using -M

[kristopher.kuhlman at gmail dot com]

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

   Summary: problems with makefile dependency generation using -M
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kristopher.kuhl...@gmail.com


Created attachment 23327
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23327
two small test codes that illustrate problem

I am in Ubuntu using a trunk build of gfortran from yesterday.

When I try to create makefile dependencies using -M, first it complains that I
need to use CPP to pre-process the code, even though there are no CPP
directives in this code.

The test code compiles file otherwise:

$ gfortran-4.6 -c makegen1.f90
$ gfortran-4.6 -c makegen2.f90
$ gfortran-4.6 -M makegen?.f90
Fatal Error: To enable preprocessing, use -cpp
Fatal Error: To enable preprocessing, use -cpp

secondly, when I add the -cpp flag, I get redundant mentions of use of a common
module.  In this test code it shows up 3 times (see constants.mod mentioned 3
times).  Can gfortran not repeat the same module several times?

$ gfortran-4.6 -cpp -M makegen?.f90
makegen1.o constants.mod: makegen1.f90
makegen2.o utility.mod: makegen2.f90 constants.mod constants.mod \
 constants.mod