[Bug fortran/53035] New: Internal Compiler Error

[Bug fortran/53035] New: Internal Compiler Error

[clerman at fuse dot net]

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

             Bug #: 53035
           Summary: Internal Compiler Error
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: clerman@fuse.net


Bugzilla fortran tech support:

  I have attached a compressed archive that should allow you to reproduce an
Internal Compiler Error. Place the file in a directory, decompress it, and
extract its entire contents. Then enter

automake
autoconf
./configure
make

  When I do this I see the following compiling the file syspars.f90:

gfortran  -I/home/norm/opcon/gfortran/focus11-bug1-4.7.1-test-dir/include -c -v
-Wall -Wextra -O3 -ffast-math -funroll-loops -std=f2003 -fno-backslash -c -o
syspars.o  syspars.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7-source/gcc-4.7-20120414/configure
--enable-languages=c,c++,fortran --enable-checking=release --disable-bootstrap
--disable-libmudflap --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=/usr/bin/gold --prefix=/usr/local/gcc-4.7
Thread model: posix
gcc version 4.7.1 20120414 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-I'
'/home/norm/opcon/gfortran/focus11-bug1-4.7.1-test-dir/include' '-c' '-v'
'-Wall' '-Wextra' '-O3' '-ffast-math' '-funroll-loops' '-std=f2003'
'-fno-backslash' '-c' '-o' 'syspars.o' '-mtune=generic' '-march=x86-64'
 /usr/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/f951
syspars.f90 -I /home/norm/opcon/gfortran/focus11-bug1-4.7.1-test-dir/include
-quiet -dumpbase syspars.f90 -mtune=generic -march=x86-64 -auxbase-strip
syspars.o -O3 -Wall -Wextra -std=f2003 -version -ffast-math -funroll-loops
-fno-backslash -fintrinsic-modules-path
/usr/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/finclude -o
/tmp/ccL2ZOZY.s
GNU Fortran (GCC) version 4.7.1 20120414 (prerelease)
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.2.1 (SUSE Linux), GMP version 4.3.2, MPFR
version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.7.1 20120414 (prerelease)
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.2.1 (SUSE Linux), GMP version 4.3.2, MPFR
version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Yours truly,

Norman S. Clerman

[Bug fortran/53035] Internal Compiler Error

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-04-19 07:35:31 UTC ---
(In reply to comment #0)
> I have attached a compressed archive that should allow you to reproduce an
> Internal Compiler Error.

I assume you forgot to attach the file - at least no file is attached.


> automake
> autoconf
> ./configure
> make

That looks like a rather large program. Thus some remarks.

First, comments and attached files to bug reports are publicly visible "for
ever"; thus, ensure that the license of the program permits the attachment.

Secondly, most of the time, programs can be reduces to a few lines of code.
That not only avoids license issues but is usually a prerequisite to be able to
find the compiler bug. Thus, we are always happy if bug reporters reduce the
test case themselves. (For the Fortran front ends - as a special service - we
might also do it ourselves - developers of other parts of GCC don't.)

Thirdly, the server admins are happy if the Bugzilla database doesn't contain
too many big attachments. (Thus, you could consider hosting the tar file
elsewhere.)


To reduce the test case, you could try Delta as described at
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction  It would be also
interesting to know whether it only fails with certain flags (like "-O3") or
always.


In any case, without a test case, it is very difficult to solve bugs ...

* * *

Regrading the ICE:

  f951: internal compiler error: in lhd_set_decl_assembler_name, at
  langhooks.c:158

the failing ASSERT is:

  /* The language-independent code should never use the
     DECL_ASSEMBLER_NAME for lots of DECLs.  Only FUNCTION_DECLs and
     VAR_DECLs for variables with static storage duration need a real
     DECL_ASSEMBLER_NAME.  */
  gcc_assert (TREE_CODE (decl) == FUNCTION_DECL
              || (TREE_CODE (decl) == VAR_DECL
                  && (TREE_STATIC (decl)
                      || DECL_EXTERNAL (decl)
                      || TREE_PUBLIC (decl))));

[Bug fortran/53035] Internal Compiler Error

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-04-19
     Ever Confirmed|0                           |1

[Bug fortran/53035] Internal Compiler Error

[norm.clerman at gmail dot com]

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

--- Comment #2 from Norman S. Clerman <norm.clerman at gmail dot com> 2012-04-25 18:13:03 UTC ---
Created attachment 27241
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27241
see original submittal

Hello Tobias,

  Sorry that I forgot to attach the file. It is attached here. I have greatly
reduced the number of the files - most in the program were not needed to
reproduce the problem. The error message remains the one I sent in the original
submittal.

  I currently have eight outstanding issues with Intel and a similar number
with PGI. I have a few with NAG, and this one with you. I could make it a
full-time job submitting bugs. But I don't have the time from my work to reduce
every problem, or to spend hours and hours trying to create a simple test case.

  In this particular case, I do not think you should have difficulty
reproducing the problem and determining its cause.

  Please don't hesitate to send me a message if something is still missing or
if you require additional information.

  Thanks for your efforts.

Yours,

Norm Clerman

  Permit me to add that the lack of deferred length, allocatable characters in
gfortran represents, for me, a major obstacle. The other three compilers I use
support them, and I use them in all but one of my major applications.

[Bug fortran/53035] Internal Compiler Error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Severity|major                       |normal

--- Comment #3 from kargl at gcc dot gnu.org 2012-04-25 19:51:18 UTC ---
(In reply to comment #2)

>   In this particular case, I do not think you should have difficulty
> reproducing the problem and determining its cause.
> 

laptop:kargl[230] ./configure
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.."
"./../.."

laptop:kargl[232] rm -rf *
laptop:kargl[233] tar xf ../focus11-bug1-4.7.1.tar.gz
laptop:kargl[234] gmake
numrutil.f90:78: Error: Can't open included file 'back_substitution_a.f90'
gmake[1]: *** [numrutil.o] Error 1
gmake[1]: Leaving directory `/usr/home/kargl/tmp/doh/src'
gmake: *** [all-recursive] Error 1

> Norm Clerman
> 
>   Permit me to add that the lack of deferred length, allocatable characters in
> gfortran represents, for me, a major obstacle. The other three compilers I use
> support them, and I use them in all but one of my major applications.

gfortran has support for a deferred type parameter.  She unfortunately
also has some nasty bugs associated with deferred type parameters, and
if those bugs were trivial to fix then the bugs would have been fixed
by now.

Permit me to add that gfortran development is currently experiencing
a lack of volunteers to help fix her.  Any particular bug is fixed
because (a) a developer is already working in that area of the compiler;
(b) the bug affects a developer's own project; (c) someone sends in
a patch; or (d) someone is willing to pay to have the bug fixed.

[Bug fortran/53035] Internal Compiler Error

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org 2012-04-25 20:15:40 UTC ---
Here's a reduced testcase (15 minutes to reduce!).

module syspars

  implicit none

  character (len = :), allocatable :: lens_dir

  contains

  function get_lens_dir () result (return_lens_dir)
    character (:), allocatable :: return_lens_dir
    return_lens_dir = lens_dir
  end function get_lens_dir

end module syspars

This is most likely a duplicate of one of the other
PRs about deferred type parameters.

[Bug fortran/53035] Internal Compiler Error

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-04-25 20:45:26 UTC ---
Reduced test case:

module SysPars
  implicit none
  character (len = :), allocatable :: lens_dir
end module SysPars

Related: PR 45170 (plus a few others)

 * * *

(In reply to comment #2)
> Sorry that I forgot to attach the file. It is attached here. I have greatly
> reduced the number of the files

I could reduce it even more - see above. I am not sure whether fixing will be
that straight forward, though.


> I could make it a full-time job submitting bugs.

And I could make it a full-time job fixing bugs ;-)


> Permit me to add that the lack of deferred length, allocatable characters in
> gfortran represents, for me, a major obstacle.

I concur that the bugs related to deferred-length (incl. this PR) and the lack
of deferred-length components is of some importance. Unfortunately, it is not
that trivial. As bug fixing and some other projects currently rank higher, it
might take a while. (Though, sometimes even larger features can get implemented
rather quickly.) As gfortran is developed by volunteers, it is a bit
unpredictable when a certain feature gets implemented and how quickly the
development progresses.

[Bug fortran/53035] ICE with deferred-length module variable

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|WAITING                     |NEW
            Summary|Internal Compiler Error     |ICE with deferred-length
                   |                            |module variable

[Bug fortran/53035] ICE with deferred-length module variable

[norm.clerman at gmail dot com]

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

--- Comment #6 from Norman S. Clerman <norm.clerman at gmail dot com> 2012-04-27 12:50:47 UTC ---
Hello,

  Thanks to everyone for following up on this. I was very used to seeing
messages that deferred length characters are not yet supported. Therefore, when
I saw the internal compiler error message, I thought it was caused by some
other problem. I see now that it is an existing one.

  I hope I did not seem too severe in my messages. I know many value the
development work being done on gfortran. (I recently attended a webinar given
by Prof. Damian Rouson on object-oriented scientific programming using modern
Fortran, and gfortran was the compiler used.)

  I am curious: How much does it cost to fix a specific bug? Is there a fixed
charge?

  I any case, I'll jump back into using gfortran whenever the current problems
are remedied. Before I added many modern Fortran features to my code, I
achieved some really impressive results using the compiler when I re-factored
one of my main applications using OpenMP.

  Enjoy your weekend.

Norm

[Bug fortran/53035] ICE with deferred-length module variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The tests in comments #4 and #5 compile with revision 187834 (2012-05-24), but
not with revision 187440 (2012-05-13). Could you test that your application
compiles with gfortran 4.8.1?

[Bug fortran/53035] ICE with deferred-length module variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The tests in comments #4 and #5 compile with revision 187834 (2012-05-24), 
> but not with revision 187440 (2012-05-13). Could you test that your application 
> compiles with gfortran 4.8.1?

I have tested that the original submittal compiles with 4.8.2. No feedback
since six months. Closing as FIXED.