#1415 parenthesis error in gfortran module file

OTHER
closed
nobody
Bug
invalid
Unknown
False
2013-02-07
2010-04-03
No

For the attached simple project, I get the following error:

bash.exe-3.1$ gfortran -o test.obj -c sfstubsf95.f90
Fatal Error: Reading module plplotp at line 491 column 35: Expected left parenthesis
gfortran.exe: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Note the platform I am using is MinGW/MSYS/Wine. This is not cross-compiled. Instead, I am using the downloaded Windows versions of MinGW (gcc-4.5.0_20100311-2) and MSYS for version 1.1.41 of Wine running on Debian Lenny, I get into the MSYS bash environment with, e.g.,

wineconsole /home/wine/mingw/MSYS/bin/bash.exe

It is possible this is a Wine platform issue but I believe this is unlikely sice I have had success building a complicated C project with the same version of MinGW/MSYS using this Wine platform. Anyhow, a quick experiment with the attached fortran source for this version of MinGW/gfortran on the
Windows platform should clear up that issue.

Requested DETAILS:

bash.exe-3.1$ gfortran -v
Using built-in specs.
COLLECT_GCC=z:\home\wine\mingw\MinGW\bin\gfortran.exe
COLLECT_LTO_WRAPPER=z:/home/wine/mingw/mingw/bin/../libexec/gcc/mingw32/4.5.0/lt
o-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0_20100311/configure --enable-languages=c,c++,ada,fo
rtran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --ena
ble-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-s
pecific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 20100311 (experimental) (GCC)

bash.exe-3.1$ ld -v
GNU ld (GNU Binutils) 2.20

bash.exe-3.1$ uname -a
MINGW32_NT-5.1 raven 1.0.14(0.47/3/2) 2010-03-17 23:02 i686 Msys

Discussion

  • Alan W. Irwin

    Alan W. Irwin - 2010-04-03

    I also confirm the issue for the 4.4 version of MinGW (gcc-full-4.4.0-mingw32-bin-2.tar.lzma) . Everything else (MSYS and Wine) was the same.

    bash.exe-3.1$ gfortran -o test.obj -c sfstubsf95.f90
    Fatal Error: Reading module plplotp at line 121 column 50: Expected left parenth
    esis
    gfortran.exe: Internal error: Aborted (program f951)
    Please submit a full bug report.
    See <http://gcc.gnu.org/bugs.html> for instructions.

    Requested Details

    bash.exe-3.1$ gfortran -v
    Using built-in specs.
    Target: mingw32
    Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,jav
    a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl
    e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab
    le-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root
    --with-mpfr=/mingw/src/mpfr/root --build=mingw32
    Thread model: win32
    gcc version 4.4.0 (GCC)
    bash.exe-3.1$

    bash.exe-3.1$ ld -v
    bash.exe: ld: command not found

    (I double-checked and ld.exe is missing from the "full" 4.4 version of MinGW).

    bash.exe-3.1$ uname -a
    MINGW32_NT-5.1 raven 1.0.14(0.47/3/2) 2010-03-17 23:02 i686 Msys

     
  • Alan W. Irwin

    Alan W. Irwin - 2010-06-09

    Much simpler Fortran source code that demonstrates the issue

     
  • Alan W. Irwin

    Alan W. Irwin - 2010-06-09

    I have now investigated the issue a lot further using MinGW 4.5.0 final. All other conditions of the test are the same as stated for the original bug report. Here is how the issue can be confirmed using the recently attached simple.f90 source code:

    wine@raven> wine gfortran -o test.obj -c simple.f90
    Fatal Error: Reading module plplotp at line 28 column 41: Expected left parenthesis
    gfortran.exe: Internal error: Aborted (program f951)
    Please submit a full bug report.
    See <http://gcc.gnu.org/bugs.html> for instructions.

    simple.f90 contains only two subroutines named plvectors_0 and plvectors_1. If I remove or rename either of them the problem disappears. Furthermore, I have done a lot of experiments with the original tarball attachment and found several other pairs of routines whose names seemed to collide with each other as well. Therefore, I suspect I have found a hash collision issue for the subroutine names.

    I assume this issue does not occur on the Microsoft Windows platform because otherwise gfortran would never have worked there except for really simple projects that happen not to have colliding subroutine names. However, I am aware of one other Wine issue (http://bugs.winehq.org/show_bug.cgi?id=22286) where they had a poorly implemented version of one of the deprecated Windows hash functions, and I wonder if gfortran is up against a similar hash collision issue for the Wine platform? I don't have the developer expertise to take this speculation any further myself, but it appears to me it would be worthwhile for the MinGW developers to review the hashing code used for subroutine names when reading module files, and I would certainly be happy to test any improvements they want to try for that code.

     
  • Earnie Boyd

    Earnie Boyd - 2013-02-07
    • labels: gcc --> gcc, wine, gfortran
    • status: open --> closed
    • milestone: --> OTHER
    • type: --> Bug
    • resolution: --> invalid
    • category: --> Unknown
    • patch_attached: --> False
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-07

    Since this is a Wine project issue I'm closing as invalid.

     
  • Alan W. Irwin

    Alan W. Irwin - 2013-02-08

    On 2013-02-07 20:36-0000 Earnie Boyd wrote:

    Since this is a Wine project issue I'm closing as invalid.

    Hi Earnie:

    I am still not entirely sure this was a Wine project issue. However, a
    recent upgrade to MinGW-4.7.0 and wine-1.5.19 finally got rid of the
    issue for me so closing the bug is appropriate regardless of
    the source of the issue.

    Alan


    Alan W. Irwin

    Astronomical research affiliation with Department of Physics and Astronomy,
    University of Victoria (astrowww.phys.uvic.ca).

    Programming affiliations with the FreeEOS equation-of-state
    implementation for stellar interiors (freeeos.sf.net); the Time
    Ephemerides project (timeephem.sf.net); PLplot scientific plotting
    software package (plplot.sf.net); the libLASi project
    (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
    and the Linux Brochure Project (lbproject.sf.net).


    Linux-powered Science


     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks