l
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jblomqvi at cc dot hut dot fi
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
--- Comment #6 from jblomqvi at cc dot hut dot fi 2005-11-05 18:12 ---
(In reply to comment #5)
> (In reply to comment #4)
> > We need to settle what kind of disk image we want for real(kind=10)
> > before resolving this for complex.
>
> I am strongly in favour o
--- Comment #2 from jblomqvi at cc dot hut dot fi 2005-11-05 18:08 ---
Patch (that also fixes PR 24174) here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00348.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24305
--- Comment #10 from jblomqvi at cc dot hut dot fi 2005-11-05 18:07 ---
Updated**2 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00348.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
--- Comment #15 from jblomqvi at cc dot hut dot fi 2005-11-01 22:09 ---
(In reply to comment #14)
> (In reply to comment #13)
> > The patch from #12 has been committed to mainline.
>
> So should this bug be closed?
>
It depends on what you consider "rea
--- Comment #3 from jblomqvi at cc dot hut dot fi 2005-10-15 20:43 ---
I think something like LONG_MAX might be appropriate. long should be the same
as size_t both on 32 and 64 bit mingw-windows, right (if 64 bit mingw indeed
exists at all)?
If LONG_MAX is too risky then at least
--- Comment #9 from jblomqvi at cc dot hut dot fi 2005-10-11 06:11 ---
Updated patch here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00572.html
--
jblomqvi at cc dot hut dot fi changed:
What|Removed |Added
--- Comment #1 from jblomqvi at cc dot hut dot fi 2005-10-11 05:55 ---
Consider this testcase (from 24174):
! { dg-do run }
! PR 24174
program kind10_io
real(kind=10) :: a,b(2), c
complex(kind=10) :: d, e, f(2)
character(len=180) :: tmp
! Test real(10) scalar and array
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jblomqvi at cc dot hut dot fi
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24305
--- Comment #8 from jblomqvi at cc dot hut dot fi 2005-10-09 21:29 ---
Well, a slightly less broken approach than the patch in #3 would be to use
sizeof(GFC_REAL_10) and sizeof(GFC_COMPLEX_10) instead of hardcoded sizes. But
the problem with this would still be 1) location of pad bytes
--- Comment #7 from jblomqvi at cc dot hut dot fi 2005-10-09 20:52 ---
(In reply to comment #5)
> > It should be noted that the patch assumes that the padding for real(10) is
> > 10
> > bytes data + 2 bytes padding. This works on i686-Linux, might not work on
>
--- Comment #6 from jblomqvi at cc dot hut dot fi 2005-10-09 19:35 ---
(In reply to comment #5)
> > It should be noted that the patch assumes that the padding for real(10) is
> > 10
> > bytes data + 2 bytes padding. This works on i686-Linux, might not work on
>
--- Comment #9 from jblomqvi at cc dot hut dot fi 2005-10-09 17:41 ---
(In reply to comment #8)
> Can you do timings with today's compiler?
>
Performance is now equivalent with g77, a factor of 500 times faster than
mainline a month ago. I don't know if any of these p
--- Comment #4 from jblomqvi at cc dot hut dot fi 2005-10-03 19:40 ---
Created an attachment (id=9866)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9866&action=view)
Testcase
And here is a test case to go with the previous patch.
Sorry my mail is b0rked at the moment so
--- Comment #3 from jblomqvi at cc dot hut dot fi 2005-10-03 19:37 ---
Created an attachment (id=9865)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9865&action=view)
Patch for PR24174, also fixes formatted output for complex(10)
libgfortran Changelog:
2005-10-03
--- Comment #1 from jblomqvi at cc dot hut dot fi 2005-10-03 09:39 ---
Ah, yes. Also see PR22519 and PR23419. Which way do we want it for unformatted?
Should kind=10 use 10 bytes of storage or should it use whatever the padded
size is? I would prefer the padded size, as otherwise we
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-29
18:59 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01841.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24112
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jblomqvi at cc dot hut dot
|dot org |fi
Status|NEW
nnot change STATUS parameter in OPEN statement
--
Summary: Reopening file with STATUS='OLD' doesn't work
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11
12:09 ---
Bud Davis is back and working on the pluggable record markers patch. Expect it
to be completed and committed within a few weeks.
There is no simple solution that is right for all situations. Gfortran uses
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11
11:15 ---
The patch from #5 has been committed to mainline, so now we lose to g77 only by
a factor of 30 and not 500 in case the file exists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11
11:10 ---
The patch from #12 has been committed to mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-09
06:44 ---
And, there's a bug in my test program. Obviously the last for loop should be
for (i = 0; i < LEN; i += 4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-09
06:41 ---
Did you by any chance mean PR 23556? That looks more like it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-08
21:25 ---
Huh, I don't see how this relates to PR 23356. Surely you wrote the wrong
number?
Anyway, I don't think memcpy is that bad. Consider the following program:
#include
#include
#include
#
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-04
09:49 ---
Removing mmap improves performance, patch:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00176.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-04
09:47 ---
This patch improves performance 20-fold for the case where the file already
exists:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00176.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-07-11
05:55 ---
Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00698.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22390
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: fortran
AssignedTo: jblomqvi at cc dot hut dot fi
ReportedBy: jblomqvi at cc dot hut dot fi
CC: gcc-bugs at gcc dot gnu dot org
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-06-20
07:25 ---
Apparently it has been decided that co-arrays will be included in the next
revision of the Fortran standard. See http://www.nag.co.uk/sc22wg5/ and
ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1639.txt
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-06-11
20:07 ---
Actually, ANINT also exhibits the same problem:
implicit none
real(4) :: r = 42.7, r2
r2 = aint (r,kind=8)
print *, 'aint: ', r2
r2 = anint (r, kind=8)
print
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-06-05
21:19 ---
Some further thoughts on this issue:
http://gcc.gnu.org/ml/fortran/2005-06/msg00084.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16339
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-06-04
17:50 ---
It seems that with current mainline, while gfortran still loses to g77 and
ifort, the difference isn't that large. Executing via strace shows that writes
are nowadays done in 8k blocks, which pro
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-24
20:02 ---
Well no, the standard does not specify how unformatted sequential record markers
are implemented. In short, gfortran uses markers of type off_t, which is 64 bits
on operating systems with large file (LFS
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-24
18:04 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02298.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-23
18:22 ---
The ICE seems to have disappeared, but it still doesn't work correctly. E.g.
implicit none
real(4) :: r = 42.0
r = aint (r,kind=8)
print *, r
end
Prints out 0.0
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-02-18
23:42 ---
Somewhat related patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01085.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-02-11
17:24 ---
You might want to check out the "global arrays" toolkit at
http://www.emsl.pnl.gov/docs/global/ga.html
GA implements the same programming model as Co-Array Fortran, but it's a
library, so a
--- Additional Comments From jblomqvi at cc dot hut dot fi 2004-10-31 15:22
---
Ok, my patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02748.html
The only major difference compared to Graham's patch is the use of
__builtin_alloca instead of gfc_getmem.
--
--- Additional Comments From jblomqvi at cc dot hut dot fi 2004-10-31 13:47
---
I'm reopening this PR since a bug crept in, apparently Paul changed the code to
be C89 conformant while it depended on C99 VLA:s to function properly. If you
look at intrinsic.c:check_intrinsic_standar
--
Bug 14993 depends on bug 17590, which changed state.
Bug 17590 Summary: Standard conformance should take intrinsics into account.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17590
What|Old Value |New Value
--- Additional Comments From jblomqvi at cc dot hut dot fi 2004-10-29 07:16
---
Here is the revised patch, which for some reason isn't flagged as belonging to
the same thread as the original:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00829.html
--
http://gcc.gnu.org/bug
42 matches
Mail list logo
