: 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
--- 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
--- 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
dot gnu dot org
ReportedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224
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
--- 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
--- 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
at gcc dot gnu dot org
ReportedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
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
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
--- 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
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
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
--- 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 #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 #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 #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
rtedBy: jkrahn at nc dot rr dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36267
18 matches
Mail list logo
