[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return stdin
--- Comment #3 from jkrahn at nc dot rr dot com 2010-07-15 21:39 --- Intel Fortran currently returns the actual device name (e.g. /dev/pts/3) but also uses stdin if the input is from a pipe. I sent a similar low-priority bug report to Intel, and they tentatively agree that the stdin string is probably not a good convention. I will let you know if I hear more. G77 and Sun Fortran treat stdio units as unnamed in all cases (tty or file I/O), setting NAME='' and NAMED=.FALSE. (Hmm... does gfortran always set NAMED=TRUE?) IMHO, if stdio units have a name, like /dev/pts/3, it should be used. If no name is available from the OS, the Fortran side should also be unnamed. Then, you are just giving Fortran the most accurate info available from the OS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44931
[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return stdin
--- Comment #4 from jkrahn at nc dot rr dot com 2010-07-15 21:49 --- I noticed that Fedora now include symlinks for /dev/stdin, /dev/stdout, /dev/stderr. It would be reasonable to use those path names if there is an interest in avoiding blank names. This convention may not hold on all platforms, but those device names probably will not exist otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44931
[Bug fortran/44931] New: For INPUT_UNIT, INQUIRE NAME= should not return stdin
The F2003 spec has the following not about the NAME= specifier: NOTE 9.63 If this specifier appears in an INQUIRE by file statement, its value is not necessarily the same as the name given in the FILE= specifier. However, the value returned shall be suitable for use as the value of the file-name-expr in the FILE= specifier in an OPEN statement. The processor may return a file name qualified by a user identification, device, directory, or other relevant information. The second part of the note suggests that a dummy name like stdin may be acceptable, but it does not conform to the first part of the note. OPEN will accept stdin as a normal filename. The easiest implementation is to return the actual stdin device name. Otherwise, just leave it unnamed. Obviously, the same is true of standard output and error units. -- Summary: For INPUT_UNIT, INQUIRE NAME= should not return stdin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44931
[Bug fortran/44830] New: Function return-type declaration with specification expression rejected for renamed derived types
$ cat bug3.f90 module mod1 type my_type integer i end type my_type end module mod1 module mod2 use mod1, only: mod1_type = my_type interface function my_func1() import mod1_type type(mod1_type) :: my_func1 end function my_func1 type(mod1_type) function my_func2() import mod1_type end function my_func2 end interface end module mod2 $ /usr/local/gfortran/bin/gfortran -c bug3.f90 | more bug3.f90:13.4: type(mod1_type) function my_func2() 1 Error: The type for function 'my_func2' at (1) is not accessible This only happens for a USE-renamed derived-type, when the function return is a derived type declared in the specification expression, as in my_func2. If the mod1 type is used without renaming, both forms are accepted. This may be related to bug41370, which is about a similar issue for character length expressions in the return type. -- Summary: Function return-type declaration with specification expression rejected for renamed derived types Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44830
[Bug fortran/44814] New: ISO_C_BINDING types inherited from a USEd module are corrupted
$ cat ptr_bug.f90 module mod1 use iso_c_binding, only: C_ptr end module mod1 module mod2 use mod1 use iso_c_binding, only: C_NULL_ptr contains subroutine bug type(C_ptr) :: ptr ptr=C_NULL_ptr end subroutine bug end module mod2 $ /usr/local/gfortran/bin/gfortran -c ptr_bug.f90 ptr_bug.f90:10.8: ptr=C_NULL_ptr 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at (1) The inherited name gets an internal _gfortran_iso_c_binding_ prefix, but the locally inherited name does not. This is mentioned in bug37829, where it was suggested to be low priority or even just an enhancement. IMHO, anything that prevents perfectly valid code form compiling should be at least normal status. -- Summary: ISO_C_BINDING types inherited from a USEd module are corrupted Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44814
[Bug fortran/44814] ISO_C_BINDING types inherited from a USEd module are corrupted
--- Comment #1 from jkrahn at nc dot rr dot com 2010-07-04 19:09 --- I updated my code to use ISO_C_BINDING directly, but still get this bug. In order to avoid corruption by the USEd module, the ISO_C_BINDING imports must all be done on the first USE statement. This code still fails: module mod1 use iso_c_binding, only: C_ptr end module mod1 module mod2 use iso_c_binding, only: C_NULL_ptr use iso_c_binding, only: C_ptr use mod1 contains subroutine bug type(C_ptr) :: ptr ptr=C_NULL_ptr end subroutine bug end module mod2 This code works, with the latter two use iso_c_binding statements merged: module mod1 use iso_c_binding, only: C_ptr end module mod1 module mod2 use iso_c_binding, only: C_ptr, C_NULL_ptr use mod1 contains subroutine bug type(C_ptr) :: ptr ptr=C_NULL_ptr end subroutine bug end module mod2 The merged statement still fails if mod1 is used first: module mod1 use iso_c_binding, only: C_ptr end module mod1 module mod2 use mod1 use iso_c_binding, only: C_ptr, C_NULL_ptr contains subroutine bug type(C_ptr) :: ptr ptr=C_NULL_ptr end subroutine bug end module mod2 This should also be tested against procedure interface IMPORT and USE statements. -- jkrahn at nc dot rr dot com changed: What|Removed |Added Summary|ISO_C_BINDING types |ISO_C_BINDING types |inherited from a USEd module|inherited from a USEd module |are corrupted |are corrupted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44814
[Bug fortran/44735] New: ICE on FORALL with character array pointer
$ cat bug3.f90 subroutine bug character(len=10) :: F_string character(len=1), dimension(:), pointer :: p_chars forall (i=1:len(F_string)) F_string(i:i) = p_chars(i) end forall end subroutine bug $ /usr/local/gfortran/bin/gfortran -c bug3.f90 bug3.f90: In function bug: bug3.f90:1:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE on FORALL with character array pointer Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735
[Bug fortran/44702] New: ISO_C_BINDING does not allow multiple USE, ONLY local names.
A USE, ... ONLY: statement is allowed to define more than one local name for the same module entity. This is broken for the ISO_C_BINDING module (and perhaps for other intrinsic modules). For example, the following does not work: program bug_program use ISO_C_Binding, only: C_ptr, C_char_ptr=C_ptr type(C_ptr) :: p1 end program bug_program It only remembers the last local-name given. This construct does work if the the ISO_C_BINDING module is USEed indirectly by USEing a normal module that USEs ISO_C_BINDING. SO, it seems likely an intrinsic-module issue. -- Summary: ISO_C_BINDING does not allow multiple USE, ONLY local names. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
[Bug preprocessor/37373] New: Variadic macros fail when generated by other macros.
The preprocessor does not parse variadic macros correctly when they are used in source code generated by other macros. I think that directives within macros are non-standard, but some standard library functions are implemented as macros when using FORTIFY_SOURCE, which can cause problems in code that is otherwise valid. For example, I am compiling code that uses macros to add extra code for handling formatted messages in some contexts, similar to the following example: #define printf(...) printf(stdout,__VA_ARGS__) #define PRINT_BEGIN(fmt) printf(fmt, #define PRINT_END) PRINT_BEGIN(%d) 100 PRINT_END; The result is: tmp.c:9:1: error: unterminated argument list invoking macro printf Obviously, the code can be modified to use macros without splitting the printf() call into separate macro evaluations. However, given that the code is valid, it would be nice if system headers could use variadic macros without breaking valid code. For now, this may only happens when invoking non-standard features like FORTIFY_SOURCE, and not with standard system headers. If so, may really be a feature request, depending on whether those features are intended to be free of side effects. -- Summary: Variadic macros fail when generated by other macros. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37373
[Bug fortran/37224] New: Request for C string literal syntax
Intel Fortran has a notation to specify C string literals by appending the letter C at the end of the string. See here for an example: http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/lref_for/source_files/pgcchcs.htm It would be nice to have this, or something similar, in gfortran. With Intel Fortran, it causes the string to interpret backslash sequences as in C, and append a NUL character. I suggested to Intel the idea of implementing a .C. unary string operator to do the same thing (I had seen it suggested on c.l.f.), with the idea of trying to fit extensions into vendor intrinsic modules instead of the traditional non-standard syntax approach. They said it would be less standard-conforming, maybe because defined-unary operators cannot be used in initialization expressions. They also stated that the C-suffix approach was a well-establish extension, although neither gfortran nor Sun have it. I am requesting that gfortran support Intel's C-string notation to improve the portability of C-interop code, if you think the extension is reasonable. It would be nice for Fortran compiler developers to agree on some other common convention, no matter what it is. One negative aspect of Intel's notation is that it would be good to support C escape sequences independent of the NUL terminator. FYI: I also suggested that they look into gfortran's work on implementing new character kinds such as UTF-8. That will also be very useful for reliable C interop. -- Summary: Request for C string literal syntax Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224
[Bug fortran/36267] New: Segfault ICE on assignment of a string pointer to a substring target
Gfortran segfaults where a string pointer is pointed to a target that is a substring reference (see example below). If I wrap the assignment in a subroutine, the pointer assignment to a substring works, so the problem is in the parser. $ cat bug.f90 character(len=1), pointer :: p character(len=10), target :: string p = string(1:1) end $ gfortran -c bug.f90 bug.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. -- Summary: Segfault ICE on assignment of a string pointer to a substring target Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36267
[Bug fortran/28378] Intrinsic extensions should be deselectable via command line
--- Comment #3 from jkrahn at nc dot rr dot com 2008-05-13 17:05 --- This is an important to fix. I just ran into problems from this. Gfortran is supposed to aim for standards conformance, but vendor extensions are not supposed to break valid code. I think this behavior is a Standards violation, and really should be a BUG and not just an enhancement. This is mainly a problem with intrinsic subroutines, because non-intrinsic functions require an EXTERNAL declaration, and automatically override intrinsic functions. This is also the main reason the INTRINSIC declaration exists. Without it, Gfortran should assume that it is an external subroutine, not an intrinsic. Some F77 compilers make the selection automatic by letting the linker find the user's subroutine first, and then link to one in a Fortran extension library if not found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28378
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #3 from jkrahn at nc dot rr dot com 2008-05-08 18:19 --- Fortran files should not be put into /usr/local/include or /usr/include. Those directories are defined for C headers. It is particularly bad to put binary files there. We should instead develop a standard location for Fortran-specific files, as is done with all non-C languages. For example: /usr/lib/gfortran/modules /usr/local/lib/gfortran/modules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #15 from jkrahn at nc dot rr dot com 2007-12-12 01:04 --- Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places burnus at gcc dot gnu dot org wrote: ... Maybe there should be a -f[no-]boz-range-check to exclude range errors just for the BOZ case. I think -fno-range-check should be enough for both, shouldn't it? My feeling is that BOZ range errors will occur often due to a poorly designed spec, but that other range errors may really be bugs. Alternatively, it might be good to a define BOZ mode flag, especially since gfortran already supports a non-standard extension, and because the vague standard means that there will be differences among compilers. F2008 draft, it re-defines B/O/Z literals, named BITS instead of BOZ. That part got dropped, see 13 August at: http://www.nag.co.uk/sc22wg5/ Well, I hope that they at least update the BOZ specification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #5 from jkrahn at nc dot rr dot com 2007-03-16 03:46 --- BOZ processing was recently broken in gfortran. I assume it relates to the issues here. The current problem is shown in this bit of code: write(*,*)'NaN(8)=',real(z'FFF8',8) end gfortran, even with -std=f2003, claims that the BOZ data is too big. Apparently, it is first converting to an UNSIGNED integer, then trying to cast to a SIGNED Fortran integer. With F2003, this form of BOZ should do a 'reinterpret-cast' of raw binary bits directly to the destination type. Even without the reinterpret cast problem, integer BOZ is not handled correctly. This expression also claims the BOZ is too large: int(z'',8) Again, it is being intepreted as an UNSIGNED int then static-cast to a signed in, thus overflowing. The traditional behavior is for all BOZ to be initially interpreted as the largets integer type supported. As usual with Fortran, that is a horrible definition. In order to define a -1 BYTE, you have to write out the whole 8-bytes worth of FF. Intel seems to use a sane (but nonstandard) method that appears to interpret initially as the smallest type that contains all of the bits specified. F95 dropped BOZ because of the lame definition, but F2003 brought it back for use mainly within REAL() and INT(), which allow the raw initial interpretation in a sensible way. The only hassle with processor dependent definitions is that the result of a given binary value depends on a processor's internal binary format. So, IEEE floats are portable, but other long/quad real numbers are not. In any case, it comes down to a raw binary value converted directly to the destination for the F2003 forms. For the older form, which is still the case in F2003 for DATA statements, it is hard to know whether to 'cheat' and allow z'FF' to define a -1 byte, or stick to the strict messed-up definition. What did G77 do? A related problem is that I am trying to create a NaN constant (parameter). I can't use REAL+BOZ, but I also cannot define real :: NaN = 0.0/0.0. In this case, divide-by-zero is invalid math, but should only be a warning and not an error. (I am speaking practically; I don't know what the standards say.) But, good news, I just discovered that this hack works: NaN = transfer(ishft(int(z'FFF8',8),32),0.0_8) I tried that a while back with gfortran and it crashed. What we really need is a NAN(kind=8) intrinsic. -- jkrahn at nc dot rr dot com changed: What|Removed |Added CC||jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #6 from jkrahn at nc dot rr dot com 2007-03-16 03:53 --- One more comment: I just checked the INT() intrisic for F2003. It actually still states that a BOZ is initially interpreted as the largest integer type (ugh!) REAL() has the correct definition of interpreting as the target REAL kind. I have to assume that they think a LARGE integer will hold all BOZ values, and can simply be down-cast. Could they actually have forgotten about negative values?!? I have not checked F2008 yet. My vote is to just ignore the standards when it comes to negative BOZ, the way Intel has done it, which I HOPE is what F2008 says. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/31144] New: Gfortran module names are not Standards compliant
Fortran Standards require that module symbol names are unique for a given module and procedure name pair. Gfortran uses an underscore prefix to prevent collisions with non-module procedures, but the double-underscore used to join the module and procedure name in not sufficient to ensure a unique symbol name. The following code snippet illustrates the problem: module m1 contains subroutine m2__m3() end subroutine m2__m3 end module m1 module m1__m2 contains subroutine m3() end subroutine m3 end module m1__m2 Compiling this code under gfortran produces a duplicate symbol error in the assembly code. The name pair should be joined with character(s) that cannot occur as part of a normal fortran name, either by using upper case (i.e. G95's _MP_) or some other character (I think one compiler uses a period). To be fair, a conflict is unlikely, and Intel Fortran has an equally broken system of module symbol names. But, the current Gfortran mechanism is clearly wrong, and should be changed the next time a binary incompatibility occurs that requires code to be recompiled anyhow. -- Summary: Gfortran module names are not Standards compliant Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
