--- 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
--- 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 tentat
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: jkra
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
--- 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
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
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
at gcc dot gnu dot org
ReportedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
d at gcc dot gnu dot org
ReportedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37373
dot gnu dot org
ReportedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224
rtedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36267
--- 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
--- 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
--- 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
>
--- Comment #13 from jkrahn at nc dot rr dot com 2007-12-11 19:40 ---
My previous post here was a bit confused by differences in F95 and F2003, and
my misunderstanding of Gfortran's BOZ extension.
As I understand the F2003 standard, the expression "INT(z'ff',1)&quo
--- 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
--- 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
: 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
18 matches
Mail list logo
