[Bug libfortran/45165] New: unix.c:fallback_access() leaks file descriptors
fd's are opened but never closed. -- Summary: unix.c:fallback_access() leaks file descriptors Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45165
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #2 from jb at gcc dot gnu dot org 2010-06-28 17:27 ---
(In reply to comment #0)
> Question 1: Why does gfortran always use "stat". Wouldn't it be better to use
> for open files:
> save = ftell(s)
> seek(s, 0, SEEK_END)
> size = ftell(s)
> seek (s, save, SEEK_SET
Yes, this would work, and we actually already have an implementation for this
(see unix.c:file_length() ), and it might be better because one doesn't need to
flush the buffer which one does need to do in order to get correct size results
from stat(). That being said, I don't think inquiring for file size is such a
common operation that flushing the buffers when this happens is an issue to
worry about.
> Question 2: I fail to see how FLUSH actually works. It seems to work most of
> the time, but I probably miss something. I somehow had expected to see a call
> to fflush - but I only see this for STDIN/STDOUT/STDERR. For the others, I
> find:
>
> raw_flush == return 0;
> buf_flush: Some action, including lseek and raw_write (= unistd.h's write)
>
> The function is called via sflush. And the FLUSH statement is file_pos.c's
> st_flush:
>
> library_start (&fpp->common);
> u = find_unit (fpp->common.unit);
> if (u != NULL)
> {
> if (u->flags.form == FORM_FORMATTED)
> fbuf_flush (u, u->mode);
> sflush (u->s);
> unlock_unit (u);
> } [...]
> library_end ();
>
> Thus: I fail to see any fflush call for non-std(out/err/in) units. Did I miss
> something?
See unix.c:buf_flush(). Called via the sflush() inline function/function
pointer thingy. libgfortran does not use C stdio
(fread/fwrite/fflush/fseek/...), but rather the lower level unbuffered POSIX IO
(read/write/lseek), with its own buffering implementation in
libgfortran/io/unix.c, see the buf_* functions.
I suspect the fflush() calls are there so that programs which mix Fortran and C
I/O to stdio/our/err work correctly (or well, hopefully at least better). But
the fflush() calls are not needed for pure gfortran IO per se.
As to the original issue, I have no idea why it fails on MinGW, and I don't
have a windows installation to test on either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug middle-end/31750] Suboptimal builtin_memset on x86 with SSE
--- Comment #4 from jb at gcc dot gnu dot org 2010-04-30 18:02 --- Some more experimentation, on different hardware, reveals that the relative performance of "rep stos" vs. loop depends heavily on the size of the object to set, the optimization options (loop unrolling etc.), and presumably on the hardware as well. The nice thing about "rep stos", is at least it's short, and in principle in the future hw manufacturers could tune the microcode to provide an optimal implementation. As I have no time to set up a comprehensive benchmark that would be required if one were to make changes to the current implementation (presumably, given the importance of memset() others have already done it), closing this as wontfix. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31750
[Bug fortran/42958] Weird temporary array allocation
--- Comment #21 from jb at gcc dot gnu dot org 2010-04-28 15:43 --- (In reply to comment #19) > (In reply to comment #18) > > 3) for the same reason you can also drop the + 1 in computing the > > allocation > > size which is currently (ubound - lbound + 1) * 4 > > Sorry, but isn't +1 needed because bounds are inclusive? > Yes. As an aside, for the 4.6 array descriptor update, there has been some discussion to move from the current (lbound, ubound, stride) triplet for every dimension to (lbound, stride, extent). Which would change these kinds of expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #14 from jb at gcc dot gnu dot org 2010-04-25 19:04 --- The GFortran behavior is now documented on 4.4, 4.5, and trunk. Closing as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #13 from jb at gcc dot gnu dot org 2010-04-25 19:01 --- Subject: Bug 40539 Author: jb Date: Sun Apr 25 19:01:06 2010 New Revision: 158707 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158707 Log: PR fortran/40539 Document LOGICAL representation Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #12 from jb at gcc dot gnu dot org 2010-04-07 18:08 --- Subject: Bug 40539 Author: jb Date: Wed Apr 7 18:07:48 2010 New Revision: 158081 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158081 Log: PR fortran/40539 Document LOGICAL representation Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #11 from jb at gcc dot gnu dot org 2010-04-07 18:01 --- Subject: Bug 40539 Author: jb Date: Wed Apr 7 18:01:24 2010 New Revision: 158080 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158080 Log: PR fortran/40539 Document LOGICAL representation Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
--- Comment #10 from jb at gcc dot gnu dot org 2010-04-04 10:56 --- I've been thinking a bit about this issue. Some observations - There are a lot of compilers, and many ways of representing logicals. Being compatible with some or all of them is, IMO, a stillborn idea. And even if we'd solve the logical issue, there are other more or less subtle issues as well. To the extent that robust interoperability is desired, the solution is to use ISO_C_BINDING. - OTOH, there is a good case to be made for being compatible with C99 _Bool. That means we can handle LOGICAL and LOGICAL(C_BOOL) identically, we can use the middle-end logical type as-is etc. However, I believe we have already accomplished this. As Tobias already noted, as the compiler can assume that the value is either 0 or 1, it can optimize based on that, and it seems this is the cause of this problem with MKL. As Fortran, contrary to C, does not allow integers to be used as logical values, in principle we never need to worry about the case where the integer value of a logical variable is neither 0 nor 1. - Doing logical comparison C-style where /= 0 is equivalent to true might be used for non-standard code playing tricks with transfer or equivalence, or for C code calling Fortran passing an integer for a logical argument (essentially the same as equivalencing integer and logical). Is this case important enough to worry about? I doubt it, but OTOH I don't think the performance difference is measurable anyways. At least on x86, a bit test instruction is no less expensive (see http://www.agner.org/optimize/instruction_tables.pdf ) than a normal comparison, and in fact http://www.agner.org/optimize/optimizing_assembly.pdf recommends to avoid the bit test instructions and instead using XOR, TEST etc. The only place where I believe there is a difference is the negation (.NOT.). If we assume the value is either 0 or 1, a xor instruction (1 cycle on current processors) is enough. If, OTOH, we do the /= 0 test, we need a TEST or CMP instruction (1 cycle) followed by a SET (1 cycle). So we lose 1 cycle; I have a hard time imagining a real application where this makes any difference. In conclusion, IMHO, if gfortran current behavior is compatible with C99 _Bool, and thus LOGICAL and LOGICAL(C_BOOL) are equivalent, this PR should be closed as WONTFIX. If not, we should fix gfortran to follow C99 behavior. In either case, there should be some documentation specifying the internal representation of LOGICALs -- jb at gcc dot gnu dot org changed: What|Removed |Added CC| |jb at gcc dot gnu dot org Last reconfirmed|-00-00 00:00:00 |2010-04-04 10:56:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #21 from jb at gcc dot gnu dot org 2010-04-01 21:11 --- Well, thanks to the quick review by Steve Kargl, it seems I proved myself wrong and I was able to commit to 4.5 with 8 minutes to spare before the freeze. Closing as fixed, again. (If anyone wants glory points for finding bugs, a quick look at the code suggests similar offset bugs could be found by exercising the FGET(C), FPUT(C), and FSEEK intrinsics). -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #20 from jb at gcc dot gnu dot org 2010-04-01 20:59 --- Subject: Bug 43605 Author: jb Date: Thu Apr 1 20:59:15 2010 New Revision: 157933 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157933 Log: PR libfortran/43605 FTELL intrinsic, take 2. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/ftell_3.f90 branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #19 from jb at gcc dot gnu dot org 2010-04-01 20:52 --- Subject: Bug 43605 Author: jb Date: Thu Apr 1 20:51:45 2010 New Revision: 157932 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157932 Log: PR libfortran/43605 FTELL intrinsic, take 2. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ftell_3.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #16 from jb at gcc dot gnu dot org 2010-04-01 20:27 --- Patch, take 2: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00072.html -- jb at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2010- |patches/2010- |03/msg01523.html|04/msg00072.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #14 from jb at gcc dot gnu dot org 2010-04-01 19:45 ---
(In reply to comment #13)
> (In reply to comment #12)
> >
> >0
> > '123456'
> >7
> > 'D'
> > 113
> >
> > I would expect '789' and 10. Am I wrong?
> >
>
> On i686 I get with trunk rev.157914:
>
>0
> '123456'
>7
> '789'
> 11
>
>
> I get the same result with ifort 11.1 and Sunstudio 12.1
> when I replace call ftell(10,i) by i=ftell(10).
Fascinating. On x86_64-unknown-linux-gnu with 4.5 r157911 I get
0
'123456'
99
'789'
99
With r157914 I get
0
'123456'
7
'D'
113
I.e. same as Dominique. The correct result, I believe, is
0
'123456'
7
'789'
11
which is what I get with 4.1.2 and 4.4.0.
Anyways, thanks for the bugreports guys, but since trunk freezes in 1h15min, a
fix for this won't make 4.5.0.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #11 from jb at gcc dot gnu dot org 2010-04-01 16:34 --- Fixed, closing. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #10 from jb at gcc dot gnu dot org 2010-04-01 16:31 --- Subject: Bug 43605 Author: jb Date: Thu Apr 1 16:31:01 2010 New Revision: 157915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157915 Log: PR libfortran/43605 FTELL incorrect for formatted files. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/ftell_3.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #9 from jb at gcc dot gnu dot org 2010-04-01 16:23 --- Subject: Bug 43605 Author: jb Date: Thu Apr 1 16:22:57 2010 New Revision: 157914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157914 Log: PR libfortran/43605 Fix FTELL for formatted files Added: trunk/gcc/testsuite/gfortran.dg/ftell_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #8 from jb at gcc dot gnu dot org 2010-04-01 08:55 --- (In reply to comment #7) > I can confirm that the patch works for both the "(a)" and the "*" case. Thanks for testing. I'll commit the patch to 4.5 tonight. > In the code, there is still some size_t reference, should > probably be gfc_offset as well: > >if (u == NULL) > return ((size_t) -1); > > Not that it would matter, though. Yeah, it won't make any difference. The real bug here is using size_t for the return value, there is PR39654 for that. (And, of course, (size_t) -1 is some very large value since size_t is unsigned, and not -1 which is the correct behavior). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #5 from jb at gcc dot gnu dot org 2010-03-31 18:42 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01523.html -- jb at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||03/msg01523.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #3 from jb at gcc dot gnu dot org 2010-03-31 15:38 --- Assigning to myself. This is probably due to ftell not taking into account fbuf. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-03-31 14:27:13 |2010-03-31 15:38:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug target/43481] huge object files generated for un-initialized data
--- Comment #3 from jb at gcc dot gnu dot org 2010-03-22 16:51 --- Seems to be a target bug, nothing to do with the Fortran frontend. Also, unless "turley" has a copyright assignment on file with the FSF (didn't find him/her in the MAINTAINERS file), the patch unfortunately cannot be accepted. -- jb at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43481
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- Comment #9 from jb at gcc dot gnu dot org 2010-01-05 19:14 --- Closing as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- Comment #8 from jb at gcc dot gnu dot org 2010-01-03 18:09 --- Subject: Bug 42420 Author: jb Date: Sun Jan 3 18:09:37 2010 New Revision: 155593 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155593 Log: PR libfortran/42420 Large file capable stat for MingW Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- Comment #7 from jb at gcc dot gnu dot org 2010-01-02 21:39 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00083.html -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00083.html Status|NEW |ASSIGNED Last reconfirmed|2009-12-18 08:51:37 |2010-01-02 21:39:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- Comment #6 from jb at gcc dot gnu dot org 2009-12-20 10:23 ---
As such the patch seems ok, however I'd prefer to avoid cluttering up the logic
with ifdefs, and secondly, we should stick to one kind of stat struct
everywhere for consistency's sake. E.g. something like
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 07aa4d9..531f6ec 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -42,13 +42,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If
/* For mingw, we don't identify files by their inode number, but by a
64-bit identifier created from a BY_HANDLE_FILE_INFORMATION. */
-#if defined(__MINGW32__) && !HAVE_WORKING_STAT
+#ifdef __MINGW32__
#define WIN32_LEAN_AND_MEAN
#include
#define lseek _lseeki64
+#define fstat _fstati64
+#define stat _stati64
+typedef struct _stati64 gfstat_t
+#ifndef HAVE_WORKING_STAT
static uint64_t
id_from_handle (HANDLE hFile)
{
@@ -91,6 +95,9 @@ id_from_fd (const int fd)
}
#endif
+#else
+typedef struct stat gfstat_t
+#endif
#ifndef PATH_MAX
#define PATH_MAX 1024
@@ -781,7 +788,7 @@ open_internal (char *base, int length, gfc_offset offset)
static stream *
fd_to_stream (int fd, int prot)
{
- struct stat statbuf;
+ gfstat_t statbuf;
unix_stream *s;
s = get_mem (sizeof (unix_stream));
@@ -1220,9 +1227,9 @@ int
compare_file_filename (gfc_unit *u, const char *name, int len)
{
char path[PATH_MAX + 1];
- struct stat st1;
+ gfstat_t st1;
#ifdef HAVE_WORKING_STAT
- struct stat st2;
+ gfstat_t st2;
#else
# ifdef __MINGW32__
uint64_t id1, id2;
@@ -1261,7 +1268,7 @@ compare_file_filename (gfc_unit *u, const char *name, int
#ifdef HAVE_WORKING_STAT
-# define FIND_FILE0_DECL struct stat *st
+# define FIND_FILE0_DECL gfstat_t *st
# define FIND_FILE0_ARGS st
#else
# define FIND_FILE0_DECL uint64_t id, const char *file, gfc_charlen_type
file_l
@@ -1318,7 +1325,7 @@ gfc_unit *
find_file (const char *file, gfc_charlen_type file_len)
{
char path[PATH_MAX + 1];
- struct stat st[2];
+ gfstat_t st[2];
gfc_unit *u;
#if defined(__MINGW32__) && !HAVE_WORKING_STAT
uint64_t id = 0ULL;
@@ -1455,7 +1462,7 @@ int
file_exists (const char *file, gfc_charlen_type file_len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (unpack_filename (path, file, file_len))
return 0;
@@ -1478,7 +1485,7 @@ const char *
inquire_sequential (const char *string, int len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (string == NULL ||
unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
@@ -1502,7 +1509,7 @@ const char *
inquire_direct (const char *string, int len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (string == NULL ||
unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
@@ -1526,7 +1533,7 @@ const char *
inquire_formatted (const char *string, int len)
{
char path[PATH_MAX + 1];
- struct stat statbuf;
+ gfstat_t statbuf;
if (string == NULL ||
unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
This is completely untested.
And, as a general observation, if mingw is ever going to be a tier-1 target for
gfortran, we need one or more maintainers who use and care about gfortran on
windows. So far all the maintainers are, to the best of my knowledge, Linux or
FreeBSD users, and any mingw support is, at best, an afterthought. Same goes
for OS X, FWIW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #6 from jb at gcc dot gnu dot org 2009-12-19 11:03 --- (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > Gentlemen, > > What is the word on this? A WONTFIX? Certainly this should be fixed, eventually. Whether it will be fixed for 4.5 or sometime later remains to be seen. Personally, I don't think it's particularly high priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug fortran/42434] New: Documentation should provide advise about clock resolutions
The gfortran documentation should advise the user about the clock resolutions she/he might expect when calling the various clock intrinsics DATE_AND_TIME, SYSTEM_CLOCK, and CPU_TIME. -- Summary: Documentation should provide advise about clock resolutions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434
[Bug fortran/28484] F2003: system_clock with real-type count_rate does not compile
--- Comment #12 from jb at gcc dot gnu dot org 2009-12-19 10:50 --- Since the actual implementation of system_clock has no use for non-integer count rates, this should be implemented by creating an integer temporary in the frontend and then calling the existing functions. Also, note that as of r155359 the integer(8) version of system_clock now provides microsecond resolution. In the future, this could be improved further by switching to using clock_gettime(CLOCK_MONOTONIC,...) which in addition to providing better resolution also gives a monotonic clock instead of a realtime clock that gettimeofday() gives. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw
--- Comment #19 from jb at gcc dot gnu dot org 2009-12-04 17:02 --- Fixed, closing. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw
--- Comment #18 from jb at gcc dot gnu dot org 2009-12-04 16:28 --- Subject: Bug 40812 Author: jb Date: Fri Dec 4 16:28:44 2009 New Revision: 154984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154984 Log: PR libfortran/40812 Large file support for MinGW Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug fortran/42131] Weird translation of DO loops
--- Comment #28 from jb at gcc dot gnu dot org 2009-12-02 09:23 --- Subject: Bug 42131 Author: jb Date: Wed Dec 2 09:22:50 2009 New Revision: 154900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154900 Log: Typo in ChangeLog entry for PR fortran/42131 Modified: trunk/gcc/fortran/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw
--- Comment #17 from jb at gcc dot gnu dot org 2009-12-01 18:58 --- Updated patch: http://gcc.gnu.org/ml/fortran/2009-12/msg00017.html -- jb at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/fortra |patches/2009- |n/2009-12/msg00017.html |12/msg00081.html| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw
--- Comment #16 from jb at gcc dot gnu dot org 2009-12-01 18:39 --- Patch -- jb at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg00081.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug fortran/42131] Weird translation of DO loops
--- Comment #27 from jb at gcc dot gnu dot org 2009-12-01 18:32 --- Subject: Bug 42131 Author: jb Date: Tue Dec 1 18:32:37 2009 New Revision: 154876 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154876 Log: PR fortran/42131 Sign test using ternary operator Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug libfortran/40812] Files > 2GB are incorrectly handled on mingw
-- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Component|fortran |libfortran Last reconfirmed|2009-12-01 16:21:16 |2009-12-01 17:59:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug fortran/41860] -finit-local-XXX clobbers -fno-automatic
--- Comment #2 from jb at gcc dot gnu dot org 2009-11-23 22:01 --- Closing as fixed, as no complaints about the committed patch have surfaced. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug fortran/41219] libgfortran build warnings
--- Comment #21 from jb at gcc dot gnu dot org 2009-10-30 22:37 --- Subject: Bug 41219 Author: jb Date: Fri Oct 30 22:37:47 2009 New Revision: 153769 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153769 Log: PR libfortran/41219 Fix build warnings Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/iso_c_binding.c trunk/libgfortran/intrinsics/unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/41860] -finit-local-XXX clobbers -fno-automatic
-- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-10-28 23:07:33 |2009-10-28 23:27:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug fortran/41860] -finit-local-XXX clobbers -fno-automatic
--- Comment #1 from jb at gcc dot gnu dot org 2009-10-28 23:25 --- Subject: Bug 41860 Author: jb Date: Wed Oct 28 23:25:08 2009 New Revision: 153689 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153689 Log: PR fortran/41860 Treat vars as save with -fno-automatic Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug fortran/41860] New: -finit-local-XXX clobbers -fno-automatic
See the thread at http://gcc.gnu.org/ml/fortran/2009-10/msg00217.html -- Summary: -finit-local-XXX clobbers -fno-automatic Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #13 from jb at gcc dot gnu dot org 2009-10-28 22:03 --- Reassigning to myself, I have a plan how to proceed with supporting proper async I/O in the library. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|jb at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/41219] libgfortran build warnings
--- Comment #6 from jb at gcc dot gnu dot org 2009-09-06 13:55 --- (In reply to comment #2) > Janne, I think the warning about "unix.c:750:15: warning: statbuf.st_mode > may > be used uninitialized" is spurious, but can you have a look? Yes, it's spurious, and I submitted a patch (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00419.html), but maybe the middle-end shouldn't warn about it anyway (see the reply by Richard Guenther). > Jerry, there is some inconsistency regarding st_parameter_dt's "saved_type". > One finds both "bt" and "dtype" assignments, which does not make sense. Does > one need both types in a union? Or can one consolidate them? > > list_read.c: dtp->u.p.saved_type = BT_LOGICAL; > list_read.c: dtp->u.p.saved_type = GFC_DTYPE_UNKNOWN; > etc. I looked into this when I redid the lower layer I/O library, and I gave up in exasperation. This dichotomy between BT_* and GFC_DTYPE_* extends into the frontend, and would require lots of tedious work and an ABI change to fix. Perhaps at the same time we change the array descriptor we could fix this too (the descriptor also needs some form of type tag, and if we adopt the TR29113 descriptor that then also influences the type tag). I added a note about this to http://gcc.gnu.org/wiki/LibgfortranAbiCleanup . As an additional bonus, note that the bt enum is different in the frontend and the library, and some of the library entry points take bt enums as arguments, which makes one one wonder how the heck all this works.. :) > In write_a_char4, one has: > const char crlf[] = "\r\n"; > write_default_char4 (dtp, crlf, 2, 0); > but the second argument should be gfc_char4_t* Right. So what is "\r\n" in terms of gfc_char4_t? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #6 from jb at gcc dot gnu dot org 2009-08-28 14:48 --- Closing as fixed -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #5 from jb at gcc dot gnu dot org 2009-08-27 17:41 --- Subject: Bug 39667 Author: jb Date: Thu Aug 27 17:40:55 2009 New Revision: 151144 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151144 Log: PR libfortran/39667 Fix testcases to not need fd_truncate. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2003_io_4.f03 trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f trunk/gcc/testsuite/gfortran.dg/fmt_exhaust.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_4.f90 trunk/gcc/testsuite/gfortran.dg/fseek.f90 trunk/gcc/testsuite/gfortran.dg/list_read_5.f90 trunk/gcc/testsuite/gfortran.dg/namelist_39.f90 trunk/gcc/testsuite/gfortran.dg/namelist_56.f90 trunk/gcc/testsuite/gfortran.dg/read_bad_advance.f90 trunk/gcc/testsuite/gfortran.dg/read_repeat.f90 trunk/gcc/testsuite/gfortran.dg/read_size_noadvance.f90 trunk/gcc/testsuite/gfortran.dg/read_x_past.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #4 from jb at gcc dot gnu dot org 2009-08-25 22:17 --- Updated patch fixing remaining fd_truncate issues with testsuite. -- jb at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/fortra|http://gcc.gnu.org/ml/gcc- |n/2009-04/msg00199.html |patches/2009- ||08/msg01388.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #12 from jb at gcc dot gnu dot org 2009-08-14 17:45 --- Subject: Bug 40863 Author: jb Date: Fri Aug 14 17:44:50 2009 New Revision: 150765 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150765 Log: PR libfortran/40863 Fix r150107 moving new symbols to C99_1.1 node Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #4 from jb at gcc dot gnu dot org 2009-07-29 12:46 --- (In reply to comment #3) > Is there a particular reason why we can not change this to off_t with 4.5.? > Yes, it would break the ABI. As it's such a minor issue, IMHO it can be postponed until we need to break the ABI for other reasons (e.g. the new array descriptor for 4.6 and so on). If one really wanted to fix it, we could have a new symbol in the library with the correct prototype, and 4.5 could use that and older releases of gfortran keep using the existing one. That can be done with symbol versioning, or just manually. But I'm not sure it's worth the bother. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug fortran/40714] [4.4/4.5 Regression] Fortran runtime error: Invalid argument
--- Comment #9 from jb at gcc dot gnu dot org 2009-07-17 19:40 --- Subject: Bug 40714 Author: jb Date: Fri Jul 17 19:40:23 2009 New Revision: 149757 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149757 Log: When finalizing I/O transfer, set current_record to 0 before returning. PR libfortran/40714 Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
[Bug fortran/40714] [4.4, 4.5 Regression] Fortran runtime error: Invalid argument
--- Comment #6 from jb at gcc dot gnu dot org 2009-07-15 21:42 --- Ok, so the problem is that due to the EOF the first read hits, the current_record marker is not properly reset to 0 at the end of the data transfer, and from that it follows that stuff isn't correctly initialized at the next I/O statement. Trying to figure out where to properly place the reset. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
[Bug fortran/40714] [4.4, 4.5 Regression] Fortran runtime error: Invalid argument
--- Comment #5 from jb at gcc dot gnu dot org 2009-07-15 17:19 --- I don't get it; for some reason bytes_left_subrecord has been set to 0, hence the seek gets messed up. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC| |jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
[Bug libfortran/40330] [4.4, 4.5 Regression] incorrect IO
--- Comment #24 from jb at gcc dot gnu dot org 2009-06-10 21:17 ---
Further reduced testcase:
program pr40330
implicit none
call s1()
call s1()
contains
subroutine s1()
character(LEN=100) :: a
a = "(3X)"
write(*,FMT='('//trim(a)//",a,' ')", ADVANCE="NO") "3"
end subroutine s1
end program pr40330
The interesting thing is, if you replace the trim(a) with trim("(3X)") then it
works. Look at -fdump-tree-original to see the difference; in the second case
the format string is a constant, in the first it's not and it's deallocated,
which might be related to why we get the valgrind errors about reading from
free'd storage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #14 from jb at gcc dot gnu dot org 2009-06-09 20:57 --- Closing as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #13 from jb at gcc dot gnu dot org 2009-06-09 20:56 --- Subject: Bug 40330 Author: jb Date: Tue Jun 9 20:55:53 2009 New Revision: 148326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148326 Log: PR libfortran/40330 Use heap memory for format cache Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-09 20:29 --- Subject: Bug 40334 Author: jb Date: Tue Jun 9 20:29:33 2009 New Revision: 148324 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148324 Log: PR libfortran/40334 backspace regression Added: trunk/gcc/testsuite/gfortran.dg/backspace_11.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #17 from jb at gcc dot gnu dot org 2009-06-04 07:40 --- (In reply to comment #16) > Can this PR now be closed? Yes, I think so. There are still some remnants of ASF in internal I/O, but I don't think it hurts. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-03 21:07 --- Subject: Bug 40330 Author: jb Date: Wed Jun 3 21:07:19 2009 New Revision: 148149 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148149 Log: PR libfortran/40330 Use heap memory for cached format strings. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #9 from jb at gcc dot gnu dot org 2009-06-03 19:19 --- Proper patch submitted. -- jb at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2009-06/msg00040.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-03 18:49 --- Created an attachment (id=17949) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17949&action=view) Proposed patch This patch seems to fix it, will formally submit as soon as it regtests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #7 from jb at gcc dot gnu dot org 2009-06-03 17:39 --- Confirmed on trunk. This seems to be due to the format caching stuff? The regression on the 4.4 branch would be explained by the I/O backport (r147887). -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-03 17:39:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-01 14:21 --- Whatever you do, as long as the Fortran standard is silent on this matter, can you hide it behind some -fC99-wankery or such option and not enable it by default, so that those of us who care less about which of (NaN, NaN) and (Inf, Inf) is the better error indicator than the roughly factor of 4 in performance for complex arithmetic can get on with our lives? -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP
--- Comment #6 from jb at gcc dot gnu dot org 2009-05-29 21:04 --- Fixed on trunk as of r147985, closing as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #2 from jb at gcc dot gnu dot org 2009-05-27 17:44 --- (In reply to comment #1) > See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup > Yes, I know; I added the note to the wiki page after I filed this bug. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #7 from jb at gcc dot gnu dot org 2009-05-27 16:42 ---
The patch below fixes the elemental_dependency_1 and vector_subscript_4
failures:
diff --git a/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
b/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
index 3e1f67b..d76fad6 100644
--- a/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
+++ b/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
@@ -40,14 +40,14 @@ PROGRAM main
b = a
CALL double((a(1:sz-1)), a(2:sz)) ! paren expression, temporary created
-! { dg-final { scan-tree-dump-times "A\.17\\\[4\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.16\\\[4\\\]" 1 "original" } }
IF (ANY(a /= (/ b(1), (2*b(i), i=1,sz-1) /))) CALL abort
b = a
CALL double(a(1:sz-1)+1, a(2:sz)) ! op expression, temporary created
-! { dg-final { scan-tree-dump-times "A\.26\\\[4\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.25\\\[4\\\]" 1 "original" } }
IF (ANY(a /= (/ b(1), (2*b(i)+2, i=1,sz-1) /))) CALL abort
@@ -59,7 +59,7 @@ PROGRAM main
b = a
CALL double(self(a(1:sz-1)), a(2:sz)) ! function expr, temporary created
-! { dg-final { scan-tree-dump-times "A\.38\\\[4\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.37\\\[4\\\]" 1 "original" } }
IF (ANY(a /= (/ b(1), (2*b(i), i=1,sz-1) /))) CALL abort
diff --git a/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
b/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
index 2044684..5c341da 100644
--- a/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
+++ b/gcc/testsuite/gfortran.dg/vector_subscript_4.f90
@@ -9,5 +9,5 @@
integer :: i(-1:1) = 1, j(3) = 1, k(3)
k = j((/1,1,1/)+i)
end
-! { dg-final { scan-tree-dump-times "A\.3\\\[3\\\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "A\.2\\\[3\\\]" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug fortran/40270] [4.5 Regression] Revision 147883 caused many Fortran regressions
--- Comment #6 from jb at gcc dot gnu dot org 2009-05-27 16:15 --- The patch in comment #5 fixes most of the issues, not all. Remaining gfortran.dg/elemental_dependency_1.f90 gfortran.dg/parameter_unused.f90 gfortran.dg/blockdata_3.f90 gfortran.dg/vector_subscript_4.f90 elemental_dependency and vector_subscript apparently fail due to the scan-tree-dump-times directive, the fix is probably just to update the test cases. parameter_unused and blockdata_3 fail because it complains that argc and argv are unused, even though the 003t.original shows that _gfortran_set_args is called as it should. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40270
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #12 from jb at gcc dot gnu dot org 2009-05-20 08:37 --- Both the mixed C/Fortran and the pure Fortran version by Dominique works as expected for me on x86_64-linux. I.e. I get the same results as reported by Dominique in comments #1 and #6. This looks like a target bug. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug libfortran/40190] DATE_AND_TIME returns GMT hour sometimes with OpenMP
--- Comment #3 from jb at gcc dot gnu dot org 2009-05-19 06:42 --- Assigning to myself. HJL is right, we should use the _r functions if available, if not we must protect the calls with a mutex. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-05-18 21:12:45 |2009-05-19 06:42:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
[Bug fortran/39782] [4.3/4.4 Regression] IO depends on uninitialised value
--- Comment #11 from jb at gcc dot gnu dot org 2009-05-15 23:50 --- Backported to 4.4 branch as r147601. Backporting to 4.3 caused regressions, so I'm tempted to just skip that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug fortran/39872] Bounds check off by one
--- Comment #5 from jb at gcc dot gnu dot org 2009-05-15 23:45 --- Subject: Bug 39872 Author: jb Date: Fri May 15 23:45:08 2009 New Revision: 147601 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147601 Log: Backport fix for PR libfortran/39872 from trunk. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39872
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #2 from jb at gcc dot gnu dot org 2009-04-30 15:12 --- Subject: Bug 39667 Author: jb Date: Thu Apr 30 15:12:37 2009 New Revision: 147004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147004 Log: Fix PR libfortran/39667 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/advance_1.f90 trunk/gcc/testsuite/gfortran.dg/advance_4.f90 trunk/gcc/testsuite/gfortran.dg/advance_5.f90 trunk/gcc/testsuite/gfortran.dg/append_1.f90 trunk/gcc/testsuite/gfortran.dg/backslash_1.f90 trunk/gcc/testsuite/gfortran.dg/backslash_2.f90 trunk/gcc/testsuite/gfortran.dg/backslash_3.f trunk/gcc/testsuite/gfortran.dg/backspace_10.f90 trunk/gcc/testsuite/gfortran.dg/backspace_3.f trunk/gcc/testsuite/gfortran.dg/backspace_4.f trunk/gcc/testsuite/gfortran.dg/backspace_5.f trunk/gcc/testsuite/gfortran.dg/backspace_8.f trunk/gcc/testsuite/gfortran.dg/backspace_9.f trunk/gcc/testsuite/gfortran.dg/complex_write.f90 trunk/gcc/testsuite/gfortran.dg/convert_implied_open.f90 trunk/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_1.f trunk/gcc/testsuite/gfortran.dg/dos_eol.f trunk/gcc/testsuite/gfortran.dg/empty_format_1.f90 trunk/gcc/testsuite/gfortran.dg/endfile.f trunk/gcc/testsuite/gfortran.dg/eof_1.f90 trunk/gcc/testsuite/gfortran.dg/eor_1.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_1.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_2.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_3.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_4.f90 trunk/gcc/testsuite/gfortran.dg/eor_handling_5.f90 trunk/gcc/testsuite/gfortran.dg/error_recovery_5.f90 trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_4.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_7.f03 trunk/gcc/testsuite/gfortran.dg/fgetc_1.f90 trunk/gcc/testsuite/gfortran.dg/fgetc_2.f90 trunk/gcc/testsuite/gfortran.dg/flush_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_exhaust.f90 trunk/gcc/testsuite/gfortran.dg/fmt_huge.f90 trunk/gcc/testsuite/gfortran.dg/fmt_read.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_2.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_3.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_4.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_5.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_7.f trunk/gcc/testsuite/gfortran.dg/fseek.f90 trunk/gcc/testsuite/gfortran.dg/ftell_1.f90 trunk/gcc/testsuite/gfortran.dg/ftell_2.f90 trunk/gcc/testsuite/gfortran.dg/func_derived_3.f90 trunk/gcc/testsuite/gfortran.dg/inquire_9.f90 trunk/gcc/testsuite/gfortran.dg/iostat_1.f90 trunk/gcc/testsuite/gfortran.dg/iostat_2.f90 trunk/gcc/testsuite/gfortran.dg/list_read_1.f90 trunk/gcc/testsuite/gfortran.dg/list_read_4.f90 trunk/gcc/testsuite/gfortran.dg/list_read_5.f90 trunk/gcc/testsuite/gfortran.dg/list_read_7.f90 trunk/gcc/testsuite/gfortran.dg/list_read_8.f90 trunk/gcc/testsuite/gfortran.dg/list_read_9.f90 trunk/gcc/testsuite/gfortran.dg/namelist_13.f90 trunk/gcc/testsuite/gfortran.dg/namelist_14.f90 trunk/gcc/testsuite/gfortran.dg/namelist_15.f90 trunk/gcc/testsuite/gfortran.dg/namelist_16.f90 trunk/gcc/testsuite/gfortran.dg/namelist_17.f90 trunk/gcc/testsuite/gfortran.dg/namelist_18.f90 trunk/gcc/testsuite/gfortran.dg/namelist_19.f90 trunk/gcc/testsuite/gfortran.dg/namelist_20.f90 trunk/gcc/testsuite/gfortran.dg/namelist_24.f90 trunk/gcc/testsuite/gfortran.dg/namelist_26.f90 trunk/gcc/testsuite/gfortran.dg/namelist_27.f90 trunk/gcc/testsuite/gfortran.dg/namelist_28.f90 trunk/gcc/testsuite/gfortran.dg/namelist_37.f90 trunk/gcc/testsuite/gfortran.dg/namelist_38.f90 trunk/gcc/testsuite/gfortran.dg/namelist_39.f90 trunk/gcc/testsuite/gfortran.dg/namelist_40.f90 trunk/gcc/testsuite/gfortran.dg/namelist_43.f90 trunk/gcc/testsuite/gfortran.dg/namelist_44.f90 trunk/gcc/testsuite/gfortran.dg/namelist_45.f90 trunk/gcc/testsuite/gfortran.dg/namelist_46.f90 trunk/gcc/testsuite/gfortran.dg/namelist_47.f90 trunk/gcc/testsuite/gfortran.dg/namelist_48.f90 trunk/gcc/testsuite/gfortran.dg/namelist_49.f90 trunk/gcc/testsuite/gfortran.dg/namelist_50.f90 trunk/gcc/testsuite/gfortran.dg/namelist_51.f90 trunk/gcc/testsuite/gfortran.dg/namelist_52.f90 trunk/gcc/testsuite/gfortran.dg/namelist_56.f90 trunk/gcc/testsuite/gfortran.dg/namelist_char_only.f90 trunk/gcc/testsuite/gfortran.dg/namelist_use.f90 trunk/gcc/testsuite/gfortran.dg/namelist_use_only.f90 trunk/gcc/testsuite/gfortran.dg/noadv_size.f90 trunk/gcc/testsuite/gfortran.dg/open_access_append_1.f90 trunk/gcc/testsuite/gfortran.dg/pad_no.f90 trunk/gcc/testsuite/gfortran.dg/pr12884.f trunk/gcc/testsuite/gfortran.dg/pr17090.f90 trunk/gcc/t
[Bug fortran/39782] [4.3/4.4 Regression] IO depends on uninitialised value
--- Comment #8 from jb at gcc dot gnu dot org 2009-04-22 21:37 --- Having a shot at backporting, assigning to myself. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-16 18:37:09 |2009-04-22 21:37:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug fortran/39782] [4.3/4.4/4.5 Regression] IO depends on uninitialised value
--- Comment #5 from jb at gcc dot gnu dot org 2009-04-18 10:05 --- Subject: Bug 39782 Author: jb Date: Sat Apr 18 10:05:34 2009 New Revision: 146308 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146308 Log: 2009-04-18 Janne Blomqvist PR libfortran/39782 * io/transfer.c (data_transfer_init): Don't flush before seek. (finalize_transfer): Remove extra flush. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #1 from jb at gcc dot gnu dot org 2009-04-17 22:18 --- Confirmed, assigning to myself. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-17 22:18:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug fortran/31243] truncating strings longer than 2**32 characters
--- Comment #6 from jb at gcc dot gnu dot org 2009-04-17 22:13 --- I'm not sure how this could be fixed in a "proper way" without breaking the procedure call ABI. Gfortran follows pretty much every other Fortran compiler in providing character length as a hidden argument of type default integer. In principle we could break this and make the length argument (s)size_t like the string functions in C/C++ do, but that would probably be a major headache for all those doing mixed C/Fortran programming the old fashioned way without ISO_C_BINDING. Of course, in principle one option could be to support larger strings as long as no procedure calls are made, but that sounds pretty confusing and flaky IMHO. Considering that string sizes larger than 2**31 are pretty rare outside of testcases, and IMHO not worth breaking the procedure call ABI for, the proper resolution for this PR would be to just print out a "compiler limit" error message like Thomas Koenig suggested. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC| |jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug libfortran/38668] advance="no": no buffering, truncate and seek
--- Comment #4 from jb at gcc dot gnu dot org 2009-04-15 19:46 --- Fixed in trunk as r146134 & r146135. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38668
[Bug c/38688] __sync_lock_test_and_set does not actually lock
--- Comment #5 from jb at gcc dot gnu dot org 2009-04-15 19:42 --- Er, sorry, wrong PR in the ChangeLog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38688
[Bug c/38688] __sync_lock_test_and_set does not actually lock
--- Comment #4 from jb at gcc dot gnu dot org 2009-04-15 19:38 --- Subject: Bug 38688 Author: jb Date: Wed Apr 15 19:38:32 2009 New Revision: 146134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146134 Log: 2009-04-15 Janne Blomqvist PR libfortran/38688 * io/transfer.c (finalize_transfer): Don't flush for advance='no'. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38688
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #12 from jb at gcc dot gnu dot org 2009-04-13 16:55 --- Fixed as of r145875 -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #11 from jb at gcc dot gnu dot org 2009-04-10 07:23 --- Subject: Bug 39665 Author: jb Date: Fri Apr 10 07:23:25 2009 New Revision: 145875 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145875 Log: 2009-04-10 Janne Blomqvist PR libfortran/39665 libfortran/39702 libfortran/39709 * io/io.h (st_parameter_dt): Revert aligned attribute from u.p.value. * io/list_read.c (read_complex): Read directly into user pointer. (read_real): Likewise. (list_formatted_read_scalar): Update read_complex and read_real calls. (nml_read_obj): Read directly into user pointer. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases
--- Comment #3 from jb at gcc dot gnu dot org 2009-04-09 21:14 --- HJ, can you check if the patch at http://gcc.gnu.org/ml/fortran/2009-04/msg00103.html fixes your problems? It is the alternative way of solving the problem that IMHO was not as clean as r145852, but if that one doesn't work I suppose we'll have to go with that one instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #10 from jb at gcc dot gnu dot org 2009-04-09 17:44 --- Subject: Bug 39665 Author: jb Date: Thu Apr 9 17:44:23 2009 New Revision: 145852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145852 Log: 2009-04-09 Janne Blomqvist PR fortran/39665 * io/io.h (st_parameter_dt): Add aligned attribute to u.p.value. * io/read.c (convert_real): Add note about alignment requirements. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #8 from jb at gcc dot gnu dot org 2009-04-08 22:36 --- Patch here: http://gcc.gnu.org/ml/fortran/2009-04/msg00103.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #6 from jb at gcc dot gnu dot org 2009-04-08 20:59 --- (In reply to comment #5) > In addition to the alignment problem, check out the case 10 and case 16 > entries > in the convert_real subroutine. After checking to see that strtold exists, > they actually go and call strtod instead of strtold. This is causing some of > my failures. Can you roll this change into your patch too. Huh? At least in my tree (r145761) they call strtold as they should: #if defined(HAVE_GFC_REAL_10) && defined (HAVE_STRTOLD) case 10: *((GFC_REAL_10*) dest) = strtold (buffer, NULL); break; #endif #if defined(HAVE_GFC_REAL_16) && defined (HAVE_STRTOLD) case 16: *((GFC_REAL_16*) dest) = strtold (buffer, NULL); break; #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #16 from jb at gcc dot gnu dot org 2009-04-08 18:24 --- Subject: Bug 39670 Author: jb Date: Wed Apr 8 18:23:55 2009 New Revision: 145767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145767 Log: 2009-04-08 Janne Blomqvist PR fortran/39670 * invoke.texi (fdollar-ok): Fix typo. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #4 from jb at gcc dot gnu dot org 2009-04-08 17:11 --- Working on a patch, assigning to myself -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-06 18:16:54 |2009-04-08 17:11:22 date|| Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug fortran/39654] New: ABI bug: FTELL intrinsic function not capable of large files
The FTELL function in libgfortran/io/intrinsics.c has the prototype extern size_t PREFIX(ftell) (int *); where the return value is the file position of the unit given in the int argument. On 32-bit platforms this will not work for files > 4 GB. The return type should be GFC_IO_INT which is a typedef for off_t which is 64-bit on LFS capable systems. -- Summary: ABI bug: FTELL intrinsic function not capable of large files Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #13 from jb at gcc dot gnu dot org 2009-03-22 10:51 --- Subject: Bug 25561 Author: jb Date: Sun Mar 22 10:51:05 2009 New Revision: 144993 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144993 Log: 2009-03-22 Janne Blomqvist PR libfortran/25561 libfortran/37754 * io/io.h (struct stream): Define new stream interface function pointers, and inline functions for accessing it. (struct fbuf): Use int instead of size_t, remove flushed element. (mem_alloc_w): New prototype. (mem_alloc_r): New prototype. (stream_at_bof): Remove prototype. (stream_at_eof): Remove prototype. (file_position): Remove prototype. (flush): Remove prototype. (stream_offset): Remove prototype. (unit_truncate): New prototype. (read_block_form): Change to return pointer, int* argument. (hit_eof): New prototype. (fbuf_init): Change prototype. (fbuf_reset): Change prototype. (fbuf_alloc): Change prototype. (fbuf_flush): Change prototype. (fbuf_seek): Change prototype. (fbuf_read): New prototype. (fbuf_getc_refill): New prototype. (fbuf_getc): New inline function. * io/fbuf.c (fbuf_init): Use int, get rid of flushed. (fbuf_debug): New function. (fbuf_reset): Flush, and return position offset. (fbuf_alloc): Simplify, don't flush, just realloc. (fbuf_flush): Make usable for read mode, salvage remaining bytes. (fbuf_seek): New whence argument. (fbuf_read): New function. (fbuf_getc_refill): New function. * io/file_pos.c (formatted_backspace): Use new stream interface. (unformatted_backspace): Likewise. (st_backspace): Make sure format buffer is reset, use new stream interface, use unit_truncate. (st_endfile): Likewise. (st_rewind): Likewise. * io/intrinsics.c: Use new stream interface. * io/list_read.c (push_char): Don't use u.p.scratch, use realloc to resize. (free_saved): Don't check u.p.scratch. (next_char): Use new stream interface, use fbuf_getc() for external files. (finish_list_read): flush format buffer. (nml_query): Update to use modified interface:s * io/open.c (test_endfile): Use new stream interface. (edit_modes): Likewise. (new_unit): Likewise, set bytes_left to 1 for stream files. * io/read.c (read_l): Use new read_block_form interface. (read_utf8): Likewise. (read_utf8_char1): Likewise. (read_default_char1): Likewise. (read_utf8_char4): Likewise. (read_default_char4): Likewise. (read_a): Likewise. (read_a_char4): Likewise. (read_decimal): Likewise. (read_radix): Likewise. (read_f): Likewise. * io/transfer.c (read_sf): Use fbuf_read and mem_alloc_r, remove usage of u.p.line_buffer. (read_block_form): Update interface to return pointer, use fbuf_read for direct access. (read_block_direct): Update to new stream interface. (write_block): Use mem_alloc_w for internal I/O. (write_buf): Update to new stream interface. (formatted_transfer_scalar): Don't use u.p.line_buffer, use fbuf_seek for external files. (us_read): Update to new stream interface. (us_write): Likewise. (data_transfer_init): Always check if we switch modes and flush. (skip_record): Use new stream interface, fix comparison. (next_record_r): Check for and reset u.p.at_eof, use new stream interface, use fbuf_getc for spacing. (write_us_marker): Update to new stream interface, don't inline. (next_record_w_unf): Likewise. (sset): New function. (next_record_w): Use new stream interface, use fbuf for printing newline. (next_record): Use new stream interface. (finalize_transfer): Remove sfree call, use new stream interface. (st_iolength_done): Don't use u.p.scratch. (st_read): Don't check for end of file. (st_read_done): Don't use u.p.scratch, use unit_truncate. (hit_eof): New function. * io/unit.c (init_units): Always init fbuf for formatted units. (update_position): Use new stream interface. (unit_truncate): New function. (finish_last_advance_record): Use fbuf to print newline. * io/unix.c: Remove unused SSIZE_MAX macro. (BUFFER_SIZE): Make static const variable rather than macro. (struct unix_stream): Remove dirty_offset, len, method, small_buffer. Order elements by decreasing size. (struct int_stream): Remove. (move_pos_offset): Remove usage of dirty_offset. (reset_stream): Remove. (do_read): Rename to raw_read, update to match new stream in
[Bug libfortran/38668] advance="no": no buffering, truncate and seek
--- Comment #3 from jb at gcc dot gnu dot org 2009-01-18 09:38 --- My patch for PR25561 fixes this partially, with the patch the strace output is: write(3, "a", 1)= 1 write(3, "a", 1)= 1 write(3, "a", 1)= 1 write(3, "a", 1)= 1 write(3, "a", 1)= 1 write(3, "a", 1)= 1 I distinctly remember that in finalize_transfer() or some related function, we flush the buffers in case of advance='no', presumably in order to get the common advance='no' case of waiting on user input correct. However, this check should be tightened to additionally check that the unit is a tty, which should fix this case. Assigning this to myself, will fix once the mega-patch for 25561 is in after 4.5 opens. -- jb at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn| |25561 AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-18 09:38:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38668
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #12 from jb at gcc dot gnu dot org 2009-01-18 09:30 --- Small patch on top of the big patch in comment #11 in order to fix a couple minor issues: http://gcc.gnu.org/ml/fortran/2009-01/msg00152.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
-- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-18 00:25:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #11 from jb at gcc dot gnu dot org 2009-01-05 22:15 --- Patch getting rid of ASF for external files: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00222.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
--- Comment #11 from jb at gcc dot gnu dot org 2009-01-05 22:14 --- Patch that improves countlines.f test (and a bunch of other things): http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00222.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug libfortran/35471] libgfortran fails with nonstandard
--- Comment #13 from jb at gcc dot gnu dot org 2008-12-23 19:36 --- As testing with a newer binutils apparently isn't forthcoming, closing as invalid. As an aside, while AFAIK this is not documented, my intuition is that libgfortran requires a somewhat up to date libc, so maybe glibc 2.1 is just too old. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35471
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
--- Comment #8 from jb at gcc dot gnu dot org 2008-11-21 07:43 --- (In reply to comment #7) > From some experiments I have done, we can make substantial improvement by > streamlining next_char. What I have in mind is reading a whole or partial > block of a file and returning a pointer. Then advancing forward next char is > a > matter of incrementing the pointer,or back as in unget_char, decrementing the > pointer. > > push_char then becomes simply an assignment. This approach would get rid of > all the function calls and and do the necessary manipulations with pointer ops > and assignments. It will take some careful rework, but I think it can be > done. > > Janne, is this what you had in mind? are you doing this? Essentially yes. I have converted the read side to use the fbuf_* machinery as well, and I have a fbuf_read(gfc_unit *, size_t *) function that fills the fbuf buffer with a specified number of bytes (by calling sread()) and then returns a pointer to the first element (the maximum size to iterate to is returned via the pointer argument). Well, that's the general idea, I still have some nasty bugs to figure out. And as I said, I think the changes are invasive enough that even if I'd get it done soon, I don't think it's 4.4 material. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug fortran/38199] missed optimization, regression: I/O performance
--- Comment #1 from jb at gcc dot gnu dot org 2008-11-20 14:04 --- I'm looking at I/O performance as part of PR 25561 (see also PR 37754, perhaps this is a dup?), but my changes are invasive enough that they are 4.5 material. Thanks for the report. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC| |jb at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-20 14:04:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug fortran/29600] MINLOC, MAXLOC and SHAPE take an optional KIND argument
--- Comment #6 from jb at gcc dot gnu dot org 2008-05-22 18:13 --- The "proper" solution, which as a side effect would take care of the combinatorial explosion issue as well, would be to inline these intrinsics. See also PR 31067. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #10 from jb at gcc dot gnu dot org 2008-05-16 17:43 --- Subject: Bug 25561 Author: jb Date: Fri May 16 17:42:44 2008 New Revision: 135433 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135433 Log: Part 1.1 of PR25561. 2008-05-15 Janne Blomqvist <[EMAIL PROTECTED]> PR libfortran/25561 * io/io.h (struct fbuf): Change pointer to position offset. * io/fbuf.c (fbuf_init): Reduce default size of buffer, ptr=>pos changes. (fbuf_reset): ptr=>pos changes. (fbuf_alloc): If the request doesn't fit, don't waste memory by keeping flushed bytes. ptr=>pos changes. (fbuf_flush): ptr=>pos changes. (fbuf_seek): Don't seek past the left tab limit, don't update active byte count. * io/open.c (new_unit): If RECL has been specified, used that as initial buffer size. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/fbuf.c trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug fortran/35632] [Regression] stream io broken on FreeBSD due to ftruncate changes.
--- Comment #14 from jb at gcc dot gnu dot org 2008-05-16 17:38 --- Subject: Bug 35632 Author: jb Date: Fri May 16 17:37:30 2008 New Revision: 135432 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135432 Log: Fix fallout from part 1 of PR25561 patch. 2008-05-16 Janne Blomqvist <[EMAIL PROTECTED]> PR libfortran/35632 * io/open.c (new_unit): Set stream position to correct value. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #9 from jb at gcc dot gnu dot org 2008-05-16 08:12 --- Patch with some improvements for part 1 here: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00924.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)
--- Comment #16 from jb at gcc dot gnu dot org 2008-05-15 18:35 --- Closing as fixed, see commit msg above. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34974
[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)
--- Comment #15 from jb at gcc dot gnu dot org 2008-05-15 18:33 --- Subject: Bug 34974 Author: jb Date: Thu May 15 18:30:29 2008 New Revision: 135388 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135388 Log: Remove XFAIL from gfortran.dg/fmt_t_7.f 2008-05-15 Janne Blomqvist <[EMAIL PROTECTED]> PR libfortran/34974 * gfortran.dg/fmt_t_7.f: Remove XFAIL, patch for PR 25561/Part 1 fixes this. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_t_7.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34974
