[Bug libfortran/24685] New: real(10) formatted input is broken for huge values
Seems that the parsing routines cannot deal with big values:
! { dg-do run }
! { dg-require-effective-target fortran_large_real }
program huge_real10_formatted
! This should be kind=10 on systems that support it
integer, parameter :: k = selected_real_kind (precision (0.0_8) + 1)
real(kind=k) :: a,b(2), c
character(len=180) :: tmp
! Test real(k) scalar and array formatted IO with big value
b(:) = huge (1.0_k)/2
print *, 'real(10) big value: ', b(1)
write (tmp, *) b
read (tmp, *) a, c
print *, 'same value read again: ', a
print *, 'difference: ', a-b(1)
! Test with really big value
b(:) = huge (1.0_k)
print *, 'huge value: ', b(1)
write (tmp, *) b
read (tmp, *) a, c ! This is line 19
print *, "We don't get this far!"
if (a /= b(1)) call abort ()
if (c /= b(2)) call abort ()
end program huge_real10_formatted
Running this produces:
real(10) big value: 5.948657476786159E+4931
same value read again: 5.948657476786159E+4931
difference: 1.751052108159553E+4915
huge value: 1.189731495357232E+4932
At line 19 of file huge_real10_formatted.f90
Fortran runtime error: Range error during floating point read
Looking at the difference, there also seems to be some problem with
arithmetic..
--
Summary: real(10) formatted input is broken for huge values
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
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
[Bug fortran/22519] Memory and binary disk layout disagree for real*10
--- 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 of real(kind=10) being written as 12 bytes on disk. > This will make life much easier for all of us, and might speed things up. > The patch I have posted for PR 24174 and PR 24305 writes the padded size (i.e. 12 bytes on x86, and AFAIK 16 bytes on x86-64 and IA-64). Now that we have gotten rid of mmap and support bulk transfers of arrays, this stuff actually makes a difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22519
[Bug libfortran/24305] Complex(10) formatted IO is broken.
--- 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
[Bug libfortran/24174] real(10) array output broken
--- 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
[Bug libfortran/21820] Really, really, horrible IO performance
--- 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 "really, really horrible IO performance". ;-) Getting rid of mmap (the patch referred to above) improved performance by a factor of 25, and I think before I made those measurements there were some patches committed which made the mmap window bigger or somesuch, improving performance compared to the situation when the bug was filed. So IMHO we have made huge improvements. OTOH we still lose to ifort by a factor of 6 or so. The major reason is that ifort does bulk transfers for implied do loops, while gfortran doesn't. Changing the code to use array transfers makes gfortran only about a factor of 1.5 slower than ifort. Personally, I think we can keep the bug around for reference, but change the priority to "enhancement". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
[Bug libfortran/24383] mingw doesn't have SSIZE_MAX
--- 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 INT_MAX should work. But yeah, in this particular case any size that is smaller than the maximum value of ssize_t would work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24383
[Bug libfortran/24174] real(10) array output broken
--- 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 Status|WAITING |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24305] Complex(10) formatted IO is broken.
--- 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 formatted IO
b(:) = 2.0_10
write (tmp, *) b
read (tmp, *) a, c
if (a /= 2.0_10) call abort()
if (c /= 2.0_10) call abort()
! Complex(10) scalar and array formatted and list formatted IO
f = cmplx ( 1.0_10, 2.0_10, 10)
d = cmplx ( huge (1.0_10), huge (2.0_10), 10)
write (tmp, *) d
read (tmp, *) e ! List formatted read doesn't work.
if (e /= d) call abort()
write (tmp, '(2(e12.4e5, 2x))') d
read (tmp, '(2(e12.4e5, 2x))') e ! Read doesn't work either
if (e /= d) call abort()
end program kind10_io
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24305
[Bug libfortran/24305] New: Complex(10) formatted IO is broken.
The problem is that the IO routines assume kind==size, and complex numbers are handled as two reals, advancing a pointer between doing the IO. For types with padding such as complex(10) this breaks as the pointer is advanced 10 bytes instead of 12 (or 16 on IA64, x86-64). It should be noted that the patch proposed for 24174 also fixes complex(10) formatted output. -- Summary: Complex(10) formatted IO is broken. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran 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
[Bug libfortran/24174] real(10) array output broken
--- 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 and 2) changing the ABI with -m128bit-long-double or similar switches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24174] real(10) array output broken
--- 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 > > other > > targets (big endian?). > > Itanium has padding to 16 bytes for 10-byte reals. > > Using 12 bytes for 10-byte reals on ia686 would mean breaking binary > compatibility with Itanium :-( Indeed, looking at http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options it seems that x86-64 also pads real(10) to 16 bytes. See the doc for the -m128bit-long-double switch. -- jblomqvi at cc dot hut dot fi changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24174] real(10) array output broken
--- 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 > > other > > targets (big endian?). > > Itanium has padding to 16 bytes for 10-byte reals. > > Using 12 bytes for 10-byte reals on ia686 would mean breaking binary > compatibility with Itanium :-( Oh dear.. Is there any functionality one can use to get information about padding (size, location of pad bytes etc.), or do we need to resort to lots of #ifdef kludging? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- 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 patches have made it into 4.0. The actual timings: Original timing (with mmap): 13.6 s. Getting rid of mmap (committed 2005-09-10 or thereabouts): 0.77 s. transfer_array (committed 2005-09-24): 0.040 s sread/swrite (the patch committed 2005-10-07): 0.026 s. g77: 0.027 s ifort 9.0: 0.153 s. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug libfortran/24174] real(10) array output broken
--- 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 I can't send the patch via the mailing list. 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 other targets (big endian?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24174] real(10) array output broken
--- 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 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/24174 * io/io.h: Add argument to prototypes. * io/list_read.c (list_formatted_read): Add kind argument, cleanup. * io/transfer.c: Add argument to transfer function pointer. (unformatted_read): Add kind argument. (unformatted_write): Likewise. (formatted_transfer_scalar): Fix for padding with complex(10). (formatted_transfer): Add kind argument, cleanup. (transfer_integer): Add kind argument to transfer call. (transfer_real): Likewise. (transfer_logical): Likewise. (transfer_character): Likewise. (transfer_complex): Likewise. (transfer_array): Likewise. (data_transfer_init): Add kind argument to formatted_transfer call. (iolength_transfer): Add kind argument, cleanup. * io/write.c (write_complex): Fix for padding with complex(10). (list_formatted_write): Add kind argument, cleanup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24174] real(10) array output broken
--- 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 take a x10 speed hit when doing array IO. But anyway, I'm pretty sure this bug is because the size in the array descriptor is 12, since real(10) is padded to 12 bytes, right? Oh, how much simpler life would be without padding. I think it would be quite simple to kludge over this bug in the library, but if we want a real solution, as in splitting the kind=size relationship I think more work is needed. I'll take a look tonight. -- jblomqvi at cc dot hut dot fi changed: What|Removed |Added BugsThisDependsOn||22519 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24112] Reopening file with STATUS='OLD' doesn't work
--- 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
[Bug libfortran/24112] Reopening file with STATUS='OLD' doesn't work
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jblomqvi at cc dot hut dot |dot org |fi Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24112
[Bug libfortran/24112] New: Reopening file with STATUS='OLD' doesn't work
Consider the following:
! Test reopening with io status='old'
! First create a test file: "touch foo"
program iostatus
open (1, file='foo', status='old')
open (1, file='foo', status='old')
end program iostatus
According to the standard (F2003 draft, section 9.4.5, page 181):
"A STATUS= specifier with a value of OLD is always allowed when the file to be
connected to the unit is the same as the file to which the unit is connected."
However, gfortran claims:
At line 5 of file iostatus.f90
Fortran runtime error: Cannot 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
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jblomqvi at cc dot hut dot fi
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24112
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- 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 64-bit record markers by default since we want compatibility between LP32 and LP64 bit platforms (which incidentally g77 doesn't provide), and we want to support records bigger than 2 GB. There has been some discussion about a byteswapio patch, but nothing has been done. Patches are welcome, of course. And, I would hardly classify the bug as "critical". If you want portable binary io you're probably better off using a library such as netcdf anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- 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
[Bug libfortran/21820] Really, really, horrible IO performance
--- 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
[Bug libfortran/23770] unaligned buffers in i/o library force use of memcpy()
--- 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
[Bug libfortran/23770] unaligned buffers in i/o library force use of memcpy()
--- 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
[Bug libfortran/23770] unaligned buffers in i/o library force use of memcpy()
--- 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
#define LEN 1
char foo[LEN], bar[LEN];
int main (void)
{
int i;
clock_t beg, as, mc, mc2;
beg = clock ();
for (i = 0; i < LEN; i++)
{
foo[i] = bar[i];
}
as = clock () - beg;
beg = clock ();
memcpy (&foo, &bar, LEN);
mc = clock () - beg;
beg = clock ();
for (i = 0; i < LEN/4; i++)
{
memcpy (&foo[i], &bar[i], 4);
}
mc2 = clock () - beg;
printf ("Copying char arrays with assignment took %d cycles.\n", as);
printf ("Using memcpy () it took %d cycles.\n", mc);
printf ("Copying 4 byte blocks (real, int) with memcpy () took %d cycles.\n",
mc2);
}
On my computer, compiled without optimization I get:
Copying char arrays with assignment took 79 cycles.
Using memcpy () it took 9 cycles.
Copying 4 byte blocks (real, int) with memcpy () took 50 cycles.
And with -O2 I get
Copying char arrays with assignment took 29 cycles.
Using memcpy () it took 9 cycles.
Copying 4 byte blocks (real, int) with memcpy () took 6 cycles.
So, memcpy is very fast.
Of course, alignment always helps, and that is perhaps an orthogonal issue wrt
memcpy vs. looping. But I'm not sure which variables you want to be better
aligned. The buffers in struct unix_stream, or? Anyway, gcc has __attribute__
((aligned (num_bytes))) which I think could be used. See
http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Variable-Attributes.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
[Bug libfortran/21820] Really, really, horrible IO performance
--- 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
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- 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
[Bug fortran/22390] Implement FLUSH statement
--- 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
[Bug fortran/22390] New: Implement FLUSH statement
Fortran 2003 defines the FLUSH statement (semantics same as for the other file positioning statements BACKSPACE, REWIND, ENDFILE). Note that gfortran already provides a flush intrinsic subroutine and function (g77 compatibility). -- Summary: Implement FLUSH statement 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22390
[Bug fortran/18918] Eventually support the co-array f95 extension in gfortran
--- 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 Something to think about once F2003 support is completed. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
[Bug fortran/20786] Can't use AINT intrinsic with KIND parameter
--- 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 *, 'anint: ', r2 end Prints out: aint:0.00 anint:0.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20786
[Bug libfortran/16339] Unformatted i/o on large arrays inefficient
--- 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
[Bug libfortran/16339] Unformatted i/o on large arrays inefficient
--- 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 probably explains the change. Here are the total times (removing the output file between each invocation): ifort 8.0: 0,109 g77 3.3: 1,349 gfortran 4.1 20050604: 1,458 Blocksizes in bytes are: ifort 8.0: 262144 g77 3.3: 4096 gfortran 4.1 20050604: 8192 Gfortran is the only one which uses mmap. Also, we can see that ifort uses a _huge_ blocksize, which probably explains why it's over 10 times faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16339
[Bug libfortran/21621] Inconsistency with binary sequential output
--- 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) support. Today, that is most OS:es in common use. g77 AFAIK uses markers of type long, that is 32-bits on most 32-bit platforms and 64 bits on 64-bit platforms. See also PR 19303. Also note that Bud Davis is apparently currently working on pluggable record markers, which should allow gfortran to add some kind of g77 compatibility flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21621
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- 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
[Bug fortran/20786] Can't use AINT intrinsic with KIND parameter
--- 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.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20786
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- 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
[Bug fortran/18918] Eventually support the co-array f95 extension in gfortran
--- 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 any standard F95 compiler should do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
[Bug fortran/17590] Standard conformance should take intrinsics into account.
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17590
[Bug fortran/17590] Standard conformance should take intrinsics into account.
--- 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_standard you see that originally it contained: int name_len; name_len = strlen(name); char msgstr[name_len + 53]; while the committed version has: int name_len; char msgstr[name_len + 53]; i.e. msgstr is allocated before the correct length is known. I'll try to fix it asap with some __builtin_alloca magic.. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17590
[Bug fortran/14993] RAN (extension) intrinsic/function not supported
-- 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 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14993
[Bug fortran/17590] Standard conformance should take intrinsics into account.
--- 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/bugzilla/show_bug.cgi?id=17590
