[Bug fortran/55197] New: Use statement for omp_lib causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55197 Bug #: 55197 Summary: Use statement for omp_lib causes ICE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: eh.toussa...@gmail.com The following short program causes an ICE in (MinGW) gfortran 4.7.0. use, intrinsic :: omp_lib, only: omp_get_num_threads end $ gfortran -c -fopenmp tmp.f90 tmp.f90:1:0: internal compiler error: in gfc_trans_use_stmts, at fortran/trans-d ecl.c:4133 Both the 'intrinsic' attribute and the 'only' clause are required to trip the error. $ gcc -v Using built-in specs. COLLECT_GCC=E:\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=e:/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,obj c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1- with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.0 (GCC)
[Bug fortran/49265] Double colon in procedure-stmt (generic interface)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49265 Erik Toussaint changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Erik Toussaint 2012-07-13 22:30:24 UTC --- Sorry to reopen this after more than a year. I think the following syntax, without the 'module' prefix, is also supposed to be ok, but it's currently not accepted (gfortran 4.7.0), with the same error message as in the original report. procedure :: bar 1 Error: Syntax error in PROCEDURE statement at (1)
[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 Erik Toussaint changed: What|Removed |Added CC||eh.toussaint at gmail dot ||com --- Comment #3 from Erik Toussaint 2012-03-02 22:17:52 UTC --- (In reply to comment #0) For both program units, if I add 'implicit none' I get the following error: !GCC$ attributes dllexport :: mydata 1 Error: Symbol 'mydata' at (1) has no IMPLICIT type So 'mydata' is treated as the identifier of a local entity. Which makes sense, because a common block and a local entity can have the same name (with certain restrictions; see 16.3.1 and 16.3.2 in f2008). Looking at the syntax of the Intel Fortran compiler, the name of the common block has to be between slashes: !DEC$ ATTRIBUTES DLLEXPORT :: /X/ http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/bldaps_for/win/bldaps_share_datadlls.htm Trying this with gfortran gives an error: !GCC$ attributes dllexport :: /mydata/ 1 Error: Invalid character in name at (1) P.s.: > !- > module m >real :: x >common /mydata/ x >!GCC$ attributes dllexport :: mydata > end module > !- > > I get the warning: > > f951: warning: ‘dllexport’ attribute directive ignored [-Wattributes] I get an error (I'm using MinGW GCC 4.6.2): m.f90:5:0: error: external linkage required for symbol 'mydata' because of 'dlle xport' attribute
[Bug fortran/84513] New: gfortran -M generates circular dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84513 Bug ID: 84513 Summary: gfortran -M generates circular dependency Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eh.toussaint at gmail dot com Target Milestone: --- When using the -M option to let gfortran generate a rule for inclusion in makefiles, the following code (all in one file) results in a circular dependency for the .mod file. $ cat foobar.f90 module bar end module program foo use bar end program ---end foobar.f90 $ gfortran -cpp -M foobar.f90 foobar.o bar.mod: foobar.f90 bar.mod It's not a major problem, because (GNU) Make simply drops it with the following message, but I'd still like to report it for the sake of neatness. make: Circular bar.mod <- bar.mod dependency dropped.
[Bug fortran/84513] gfortran -M generates circular dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84513 --- Comment #2 from Erik Toussaint --- Perhaps similar in the sense that in both cases the logic lacks a final check. I don't know anything about the code that handles this, but it appears that the source file gets parsed, and if a module is encountered the name of the .mod file is added to the list of targets (to the left of the colon), and if a use statement is encountered the name of the .mod file is added to the list of dependencies (to the right of the colon). Adding the name of the .mod file for a module that is defined in the current source file to the list of dependencies, though, makes no sense. A final step that checks for this and deletes such .mod files from the list of dependencies if they also exist in the list of targets could resolve this.
[Bug fortran/84672] New: -fcheck=bounds gives runtime error on allocation on assignment with implicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84672 Bug ID: 84672 Summary: -fcheck=bounds gives runtime error on allocation on assignment with implicit type conversion Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eh.toussaint at gmail dot com Target Milestone: --- The following program gives a runtime error when compiled with -fcheck=bounds. program foo implicit none real :: x(2) integer, allocatable :: iy(:) x = 1 iy = x write(*, *) iy end program $ gfortran -fcheck=bounds foo.f90 -o foo.exe && ./foo.exe At line 8 of file foo.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'iy' (18711 90219/2) Error termination. Backtrace: Could not print backtrace: libbacktrace could not find executable to open #0 0x6f8aecb4 #1 0x6f8a11ce #2 0x6f88105c #3 0x40160b #4 0x4017b5 #5 0x401287
[Bug fortran/49265] New: Double colon in procedure-stmt (generic interface)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49265 Summary: Double colon in procedure-stmt (generic interface) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: eh.toussa...@gmail.com In Fortran 2008 the (module) procedure statement in a generic interface can contain a double colon, according to R1206: R1206 procedure-stmt is [ MODULE ] PROCEDURE [ :: ] procedure-name-list When I try to compile the following module with gfortran 4.7-20110423 I get an error. module m1 implicit none interface foo module procedure :: bar end interface contains subroutine bar end subroutine end module $ gfortran -c -std=f2008 m1.f90 m1.f90:4.23: module procedure :: bar 1 Error: Syntax error in MODULE PROCEDURE statement at (1) (The '1' indicates the double colon as the location of the error.) If I remove the double colon the file compiles without error - which is expected, as the optional double colon didn't appear in the rule in previous versions of the standard. $ gcc -v Using built-in specs. COLLECT_GCC=d:\Programs\MinGW\gcc47\bin\gcc.exe COLLECT_LTO_WRAPPER=d:/programs/mingw/gcc47/bin/../libexec/gcc/i686-pc-mingw32/4 .7.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ../src/configure --prefix=/mingw --with-gmp=/mingw --with-mpfr= /mingw --with-mpc=/mingw --disable-nls --enable-languages=c,c++,fortran --enable -libgomp --disable-win32-registry Thread model: win32 gcc version 4.7.0 20110423 (experimental) (GCC)
