[Bug fortran/42089] New: Problems when readinf partial records on direct access files
-- Summary: Problems when readinf partial records on direct access files Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42089
[Bug fortran/42090] New: Problems when reading partial records in formatted direct access files
Consider the following: Wot now ? cat da.f90 Program da Implicit None Real :: a, b a = 1.1 b = 2.2 Open( 10, File = 't.dat', Form = 'Formatted', Access = 'Direct', Recl = 12 ) Write( 10, rec = 1, fmt = '( f6.4, /, f6.4 )' ) a, b Close( 10 ) a = -1.0 b = -1.0 Open( 10, File = 't.dat', Form = 'Formatted', Access = 'Direct', Recl = 12 ) Read( 10, rec = 1, fmt = '( f6.4, /, f6.4 )' ) a, b Write( *, '( Partial record 1, t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f6.4 )' ) a, b Write( *, '( Partial record 2, t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f12.4, /, f12.4 )' ) a, b Write( *, '( Full record 1, t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f12.4 )' ) a, b Write( *, '( Full record 2, t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f6.4, 6x, /, f6.4, 6x )' ) a, b Write( *, '( Full record with 6x, t25, 2( f6.4, 1x ) )' ) a, b Read( 10, rec = 1, fmt = '( f6.4 )' ) a Read( 10, rec = 2, fmt = '( f6.4 )' ) b Write( *, '( Record at a time, t25, 2( f6.4, 1x ) )' ) a, b End Program da Wot now ? ~/Download/usr/local/gfortran/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20091116 (experimental) [trunk revision 154218] Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? ~/Download/usr/local/gfortran/bin/gfortran -W -Wall -pedantic -fbounds-check -g -O2 da.f90 Wot now ? ./a.out Partial record 11. 0. Partial record 21. 0. Full record 1 1. 2. Full record 2 1. 2. Full record with 6x 1. 2. Record at a time1. 2. Wot now ? Note that when reading partial records gfortran gets the value of b wrong. Compare g95 and the sun fortran compiler: Wot now ? g95 --version G95 (GCC 4.0.3 (g95 0.92!) Mar 27 2009) Copyright (C) 2002-2008 Free Software Foundation, Inc. G95 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of G95 under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? g95 -W -Wall -pedantic -fbounds-check -g -O2 da.f90 Wot now ? ./a.out Partial record 11. 2. Partial record 21. 2. Full record 1 1. 2. Full record 2 1. 2. Full record with 6x 1. 2. Record at a time1. 2. Wot now ? f90 -V f90: Sun Fortran 95 8.4 Linux_i386 2009/06/03 Usage: f90 [ options ] files. Use 'f90 -flags' for details Wot now ? f90 da.f90 Wot now ? ./a.out Partial record 11. 2. Partial record 21. 2. Full record 1 1. 2. Full record 2 1. 2. Full record with 6x 1. 2. Record at a time1. 2. I've also checked against the intel, portland group, pathscale and cray compilers and they all give what I think is the correct result, i.e. the same as g95 and the sun compiler Also sorry about screwing up the first attempt at submission ! -- Summary: Problems when reading partial records in formatted direct access files Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug fortran/41099] New: openMP include file causes errors when compiling with standards checking
Due to non-standard code in the supplied openMP header file omp_lib.h compiling with standards checking on results in errors due to the include file and not the users code: Wot now ? uname -a Linux kingswood.nag.co.uk 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux Wot now ? ~/Download/usr/local/gfortran/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20090817 (experimental) [trunk revision 150822] Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? cat omp.f90 Program annoying Include 'omp_lib.h' End Program annoying Wot now ? ~/Download/usr/local/gfortran/bin/gfortran -fopenmp -std=f95 omp.f90 omp_lib.h:45.15: Included at omp.f90:3: logical*4 omp_get_dynamic, omp_get_nested 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:47.15: Included at omp.f90:3: logical*4 omp_test_lock, omp_in_parallel 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:50.15: Included at omp.f90:3: integer*4 omp_get_max_threads, omp_get_num_procs 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:52.15: Included at omp.f90:3: integer*4 omp_get_num_threads, omp_get_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:54.15: Included at omp.f90:3: integer*4 omp_test_nest_lock 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:64.15: Included at omp.f90:3: integer*4 omp_get_thread_limit, omp_get_max_active_levels 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:65.15: Included at omp.f90:3: integer*4 omp_get_level, omp_get_ancestor_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:66.15: Included at omp.f90:3: integer*4 omp_get_team_size, omp_get_active_level 1 Error: Nonstandard type declaration INTEGER*4 at (1) Wot now ? The nett result is it is difficult to check for non-standard code in programs that include omp_lib.h, which is irritating if portability is extremly important to you. ( Yes, I know there is a work around by using the module rather than including the file, but both should work ! ) Actually this is a more general problem as MPI include files often have similar non-standard code, with the same resulting irritation. What would be nice is some way to say that you wish to ignore all problems caused by a given set of include files. However it would also be nice to fix the include file ! -- Summary: openMP include file causes errors when compiling with standards checking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41099
[Bug fortran/41102] New: openMP include file causes errors when compiling with standards checking
Due to non-standard code in the supplied openMP header file omp_lib.h compiling with standards checking on results in errors due to the include file and not the users code: Wot now ? uname -a Linux kingswood.nag.co.uk 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux Wot now ? ~/Download/usr/local/gfortran/bin/gfortran --version GNU Fortran (GCC) 4.5.0 20090817 (experimental) [trunk revision 150822] Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Wot now ? cat omp.f90 Program annoying Include 'omp_lib.h' End Program annoying Wot now ? ~/Download/usr/local/gfortran/bin/gfortran -fopenmp -std=f95 omp.f90 omp_lib.h:45.15: Included at omp.f90:3: logical*4 omp_get_dynamic, omp_get_nested 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:47.15: Included at omp.f90:3: logical*4 omp_test_lock, omp_in_parallel 1 Error: Nonstandard type declaration LOGICAL*4 at (1) omp_lib.h:50.15: Included at omp.f90:3: integer*4 omp_get_max_threads, omp_get_num_procs 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:52.15: Included at omp.f90:3: integer*4 omp_get_num_threads, omp_get_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:54.15: Included at omp.f90:3: integer*4 omp_test_nest_lock 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:64.15: Included at omp.f90:3: integer*4 omp_get_thread_limit, omp_get_max_active_levels 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:65.15: Included at omp.f90:3: integer*4 omp_get_level, omp_get_ancestor_thread_num 1 Error: Nonstandard type declaration INTEGER*4 at (1) omp_lib.h:66.15: Included at omp.f90:3: integer*4 omp_get_team_size, omp_get_active_level 1 Error: Nonstandard type declaration INTEGER*4 at (1) Wot now ? The nett result is it is difficult to check for non-standard code in programs that include omp_lib.h, which is irritating if portability is extremly important to you. ( Yes, I know there is a work around by using the module rather than including the file, but both should work ! ) Actually this is a more general problem as MPI include files often have similar non-standard code, with the same resulting irritation. What would be nice is some way to say that you wish to ignore all problems caused by a given set of include files. However it would also be nice to fix the include file ! -- Summary: openMP include file causes errors when compiling with standards checking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian dot bush at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #5 from ian dot bush at nag dot co dot uk 2009-08-18 16:46 --- Subject: Re: openMP include file causes errors when compiling with standards checking burnus at gcc dot gnu dot org wrote: --- Comment #4 from burnus at gcc dot gnu dot org 2009-08-18 16:08 --- (In reply to comment #3) For C and C++, most diagnostics are disabled by default for code in system headers. Shouldn't Fortran do something equivalent? Good question. The problem is that with include somebig_chunk_of_code.f90 one can include other code, which does not necessarily contain just PARAMETERs (constants) and COMMONs but actual code. For instance octopus (tddft.org) does this: It has a MODULE and includes one or two other files in it, which contain subroutines/functions belonging to the MODULE but are for maintenance reasons in a separate file. (Fortran 2008's submodules would be a better replacement.) Also Fortran doesn't have the concept of system headers, so how should the compiler decide what is a system header or not ? In some cases, like openMP it's reasonably clear, but for third party software it's difficult. Hence my suggestion in the original bug report to somehow allow the user to specify that diagnostics from certain include files should be ignored. Also thanks for fixing this so quickly, the joys of open source !! I've lodged similar bug reports to Cray ( around 6 months ago ) and IBM ( around 6 years ago !! ) about their mpif.h files with absolutely no joy. Also I hope I'm replying to the right place, I'm new around here ... Ian The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
[Bug fortran/41102] openMP include file causes errors when compiling with standards checking
--- Comment #7 from ian dot bush at nag dot co dot uk 2009-08-18 16:58 --- Subject: Re: openMP include file causes errors when compiling with standards checking joseph at codesourcery dot com wrote: --- Comment #6 from joseph at codesourcery dot com 2009-08-18 16:52 --- Subject: Re: openMP include file causes errors when compiling with standards checking On Tue, 18 Aug 2009, ian dot bush at nag dot co dot uk wrote: Also Fortran doesn't have the concept of system headers, so how should the compiler decide what is a system header or not ? In some cases, like openMP it's reasonably clear, but for third party software it's difficult. Hence my suggestion in the original bug report to somehow allow the user to specify that diagnostics from certain include files should be ignored. System headers are headers in system header directories: directories of headers provided by the system (not necessarily just those that come with GCC) and are searched by default. In the present case, the file is installed by gcc in libsubdir/finclude, and I don't know what other system directories gfortran might search by default. OK, my misunderstanding on a piece of terminology. Thanks for educating me. But still the option to say please ignore diagnostics generated in this header/include file would be useful, Ian The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41102
