--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-08 02:03
---
First, thanks for the trace.
Please try this patch. In the meantime, I need to make sure I have the
backward compatibility with 4.3 runtime OK. I have one other spot to check in
the code.
Index: transfer.c
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-09 03:20
---
Subject: Bug 38430
Author: jvdelisle
Date: Tue Dec 9 03:19:09 2008
New Revision: 142575
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142575
Log:
2008-12-08 Jerry DeLisle <[EMAI
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-10 13:45
---
Confirmed fix on ppc64-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37469
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-12 03:33
---
I am investigating this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38437
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-12-12 03:58
---
After creating some dummy data in the file fort.1 I am able to compile and
execute the program. I did have to declare NA and NB as parameters with some
value and also declare the arrays with those dimensions
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:29
---
I am trying not to lose sight of the original problem in comment zero.
However, the decimal output alignment problem fixed in comment 9 still exists
with -m32 on x86-64 and I can see it with 32 bit windows as
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:32
---
I have also found on pr38472 some odd behaviour at -m32. That we see this with
an integer output has my concern level up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:42
---
Reduced test case. Fails at -m32
program IntAdtest
integer, parameter :: i8_ = Selected_Int_Kind(18) ! = integer*8
integer(i8_) :: value
value = -9223372036854775807_i8_ -1
write(*, '(i22)&#x
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-13 16:28
---
I have isolated the problem to gfc_itoa. gfc_itoa returns a string. The number
of digits is determined from the strlen of that string. At -m32, that string
length (digits, see below) is off by one. I
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-12-13 19:34
---
Testing this.
Index: write.c
===
--- write.c (revision 142574)
+++ write.c (working copy)
@@ -600,9 +600,16 @@ write_decimal
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-13 21:08
---
Please confirm. Is the output for this correct?
write(*, '(g0.3)') 0.1
write(*, '(g0.9)') 1.0
write(*, '(g0.5)') 29.23
write(*, '(g0.8)') -28.4
write(*, '(g0.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-13 21:19
---
Disregard comment #2, I found the relevant text describing this that I needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38398
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-13 23:54
---
Let's try this again. I need verification that I am interpreting the comments
correctly. With this:
! { dg-do compile }
! { dg-options "-std=f2008" }
! PR36725 Compile time error for g0 edit d
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-14 06:52
---
Subject: Bug 38504
Author: jvdelisle
Date: Sun Dec 14 06:50:53 2008
New Revision: 142747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142747
Log:
2008-12-13 Jerry DeLisle
PR li
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-14 07:00
---
Subject: Bug 38504
Author: jvdelisle
Date: Sun Dec 14 06:58:38 2008
New Revision: 142748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142748
Log:
2008-12-13 Jerry DeLisle
PR li
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-12-14 07:01
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-12-20 18:34
---
Created an attachment (id=16950)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16950&action=view)
Revised patch
This is latest version of the patch. Please test.
--
http://gcc.gnu.org/b
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-12-21 05:28
---
This little patch eliminates the misalignment of output characters with -m32
and gets rid of a many many valgrind errors.
@@ -628,7 +637,7 @@ output_float_FMT_G_ ## x (st_parameter_d
\
while (low <= h
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-12-21 21:21
---
Subject: Bug 38398
Author: jvdelisle
Date: Sun Dec 21 21:20:29 2008
New Revision: 142870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142870
Log:
2008-12-21 Jerry DeLisle
PR fortr
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-21 21:25
---
Subject: Bug 38398
Author: jvdelisle
Date: Sun Dec 21 21:23:52 2008
New Revision: 142871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142871
Log:
2008-12-21 Jerry DeLisle
PR li
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-21 22:08
---
Subject: Bug 38398
Author: jvdelisle
Date: Sun Dec 21 22:06:34 2008
New Revision: 142876
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142876
Log:
2008-12-21 Jerry DeLisle
PR li
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-22 05:18
---
The test case passes at r142147 and fails at r142148
The patch to pr34820 caused this regression
PR fortran/34820
* trans-expr.c (gfc_conv_function_call): Remove all code to
deallocate
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-12-22 06:23
---
I think that this PR could be considered resolved by the new g0 edit
descriptor.
If, for example, you have three items to emit, the following will do so
regardless of their type.
program minimal_output
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-22 06:33
---
Here is another variation on this:
print'(xg0)',(i,i=1,6)
print'(6(xg0))',(i,i=1,6)
end
$ ./a.out
1
2
3
4
5
6
1 2 3 4 5 6
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-12-22 14:55
---
Subject: Bug 37472
Author: jvdelisle
Date: Mon Dec 22 14:53:37 2008
New Revision: 142884
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142884
Log:
2008-12-22 Jerry DeLisle
PR li
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-12-22 20:53
---
Regression testing now and will commit when complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38602
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2008-12-22 21:27
---
Yes, so far I am only working with 4.4. Regardless, it appears that on this
platform the width is being computed incorrectly. I count 20 stars in the
field width. The required field width for the output on
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-12-22 23:12
---
Subject: Bug 35780
Author: jvdelisle
Date: Mon Dec 22 23:11:29 2008
New Revision: 142889
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142889
Log:
2008-12-22 Paul Thomas
PR fortr
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-22 23:18
---
Subject: Bug 35780
Author: jvdelisle
Date: Mon Dec 22 23:16:44 2008
New Revision: 142890
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142890
Log:
2008-12-22 Paul Thomas
PR fortr
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-22 23:39
---
Patch committed, fixed on trunk, 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38602
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-12-23 01:33
---
Subject: Bug 38602
Author: jvdelisle
Date: Tue Dec 23 01:32:33 2008
New Revision: 142898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142898
Log:
2008-12-22 Paul Thomas
PR fortr
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-12-23 01:35
---
Subject: Bug 38602
Author: jvdelisle
Date: Tue Dec 23 01:34:13 2008
New Revision: 142899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142899
Log:
2008-12-22 Paul Thomas
PR fortr
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-12-23 02:10
---
Fixed on 4.3, closing. Thanks everyone for the help with this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-23 23:43
---
Closing, fixed on 4.4
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-25 19:45
---
g77 runtime accepts this and prints:
character(len=25) :: str
str = '(1PD24.15E4)'
write (*,'(1PD24.15E4)') 1.0d0
WRITE (*,str) 1.0d0
end
$ g77
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-28 03:53
---
Something is amiss. Yes the change to fmt_g0_1.f08 is necessary. The output
should have no blank spaces in the fields for floating point.
This test case runs fine here, maybe your trunk is not fully updated
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-28 20:55
---
Daniel, it can't hurt to look.
Also, I have a format data hashing/caching patch in the works. This avoids
re-parsing format strings if they have already been parsed once such as in a
loop containin
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-28 21:02
---
Created an attachment (id=16997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16997&action=view)
Patch that splits formatted read and write
This is the patch mentioned in comment 0. This patch
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-12-29 20:47
---
I will try to close this again. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-01-04 06:08
---
hmm, forgot all about this. I will apply the patch, retest, and commit if OK
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
33.95670
--
Summary: Default BLANK= mode for internal units is wrong
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: jvdelisle at gcc dot gnu dot org
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-01-05 21:43
---
>From the standard:
"an internal file or a preconnected file that has not been opened is treated as
if the file had been opened with BLANK = 'NULL'."
Patch on its way.
This i
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-01-05 22:55
---
Subject: Bug 38735
Author: jvdelisle
Date: Mon Jan 5 22:55:15 2009
New Revision: 143102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143102
Log:
2009-01-05 Jerry DeLisle
PR li
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-01-05 22:57
---
Subject: Bug 38735
Author: jvdelisle
Date: Mon Jan 5 22:57:30 2009
New Revision: 143103
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143103
Log:
2009-01-05 Jerry DeLisle
PR li
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-01-06 00:30
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-01-09 03:00
---
I am looking into it. Thanks for the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-01-09 03:32
---
I have reviewed our library code to see if we are handling BLANK=status
correctly. AFAICT we are doing this right. I was concerned with your report
because I thought maybe we were getting a side effect from the
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-01-09 04:03
---
g77, ifort, and gfortran 4.4 all pass this test case which should print
nothing.
c { dg-do run }
c PR38097 I/O with blanks in exponent fails; BN edit descriptor
c Test case derived from reporter
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-01-09 05:34
---
With Janne's patch and some minor tweaks.
countlines.f
gfortran 4.4 patched: 2.2 seconds
gfortran 4.3: 3.5 seconds
g77 : 2.7 seconds
ifort : 1.1 se
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-01-11 16:43
---
Reviewing code carefully, I found the following. I can not confirm this is the
problem, but removing this portion of code does not cause a regression in our
current testsuite. This snippit was left over from
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-01-13 03:44
---
Great work Jack. Now we have a test case to work with.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-01-13 04:14
---
The problem is in read.c. In reading floats we are not catching invalid
exponent characters. The BN patch just revealed this bug that has been there
all along.
The string can be just about anything with an &#
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-01-13 04:36
---
Here is a patch. If the character is not a digit or a blank, we exit the loop
and skip the test for not a digit. DUH! (first part of patch is just an
indentation fix)
Index: read.c
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:40
---
Subject: Bug 38772
Author: jvdelisle
Date: Tue Jan 13 05:40:36 2009
New Revision: 143327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143327
Log:
2009-01-12 Jerry DeLisle
PR li
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:53
---
Subject: Bug 38772
Author: jvdelisle
Date: Tue Jan 13 05:53:07 2009
New Revision: 143328
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143328
Log:
2009-01-12 Jerry DeLisle
PR li
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:57
---
Thanks for help Jack. The patch committed does fix the test case you provided.
Please double check with xplor-nih and if fixed as expected we can close this
PR.
--
jvdelisle at gcc dot gnu dot org changed
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-01-13 06:07
---
Reply to comments 16 and 17 which I did not see before my commit. Please make
sure the original r143102 is in place when you apply latest patch. It does
seem bothersome that the xplor-nih is so sensitive. It
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2009-01-14 03:05
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-01-14 03:30
---
I propose that we close this as WONT FIX as well, for three reasons:
1) There are other ways to do these things and it is not necessary to use
internal I/O to do it. Character strings can be used for format
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-01-16 02:57
---
ifort (IFORT) 10.1 20080801
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
$ ./a.out
T F
I want to get my head around this too. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-17 12:54
---
With Dominique's reduced test case I see three valgrind errors. Actual output
is fine. I am looking further.
==4359== Conditional jump or move depends on uninitialised value(s)
==4359==at 0x43793D: s
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-01-17 16:40
---
Comment 20 was compiled with -static -g. Each error is at functions outside
libgfortran. Valgrind reports zero errors if the test case is compiled without
-static. I suspect comment 20 is misleading
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-01-18 01:33
---
Closing, the code is invalid Fortran
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-01-21 06:51
---
I have been doing some digging. The "PD" edit descriptor is clearly defined in
the Fortran 66 standard in sections 7.2.3.1 and 7.2.3.5. The form of the scale
factor is nP
The D designates that th
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-01-22 03:05
---
Further information: PD is not the problem here at all. The problem is that
when using the D edit descriptor, one is not allowed to also specify the
exponent digits.
Thus: '(1pD24.15)' is va
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-01-23 05:46
---
gfortran's current format parser is completely lost by the time an error is
thrown. I have a patch that detects the actual error and the locus is spot on.
I am fixing both compile time and run time to r
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-01-24 18:11
---
Regarding the question on location markers: If gfc_error or gfc_warning are
used with the %C designator, only the current line is picked up. The actual
format token locus is saved in the format_locus pointer
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-01-27 05:00
---
I am going to look at this for a bit.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-05-16 13:38
---
Yes, lets skip 4.3 and close this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-05-16 13:46
---
Nice for a one liner patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-05-17 12:58
---
Concur. Rather than use -fdefault-integer-8, consider using selected_int_kind
and explicitly declaring size of integers.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-05-20 00:16
---
Subject: Bug 37754
Author: jvdelisle
Date: Wed May 20 00:16:38 2009
New Revision: 147725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147725
Log:
2009-05-19 Jerry DeLisle
PR li
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-05-25 03:07
---
Subject: Bug 39872
Author: jvdelisle
Date: Mon May 25 03:07:00 2009
New Revision: 147842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147842
Log:
2009-05-24 Jerry DeLisle
D
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-05-25 03:07
---
Subject: Bug 35732
Author: jvdelisle
Date: Mon May 25 03:07:00 2009
New Revision: 147842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147842
Log:
2009-05-24 Jerry DeLisle
D
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 22423
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 38668
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39782
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 25561
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39667
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 38654
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 37754
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39664
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39665
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backp
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:47
---
Fixed on 4.4, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-05-31 00:17
---
I might as well fix this one while I am doing other edit descriptors.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-06-04 01:13
---
Confirmed on 4.4 and 4.5. I checked with 4.3, ifort, open64, and Sun
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Summary|4.5 regression: changed |4.4,4.5 regression: changed
|BACKSPACE behaviour
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-06-05 22:58
---
Not a bug in gfortran.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-06-06 16:08
---
In the test case, the the first EOF is generated in transfer.c (hit_eof) which
sets the end file conditions. The second EOF is generated in list_read.c:1689.
When returning from he error condition, the end file
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-06-06 16:09
---
Correction "have not" regtested the patch above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-06-07 17:40
---
Subject: Bug 40334
Author: jvdelisle
Date: Sun Jun 7 17:40:24 2009
New Revision: 148251
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148251
Log:
2009-06-07 Jerry DeLisle
PR li
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-06-07 18:57
---
Subject: Bug 40008
Author: jvdelisle
Date: Sun Jun 7 18:57:43 2009
New Revision: 148252
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148252
Log:
2009-05-31 Jerry DeLisle
PR fortr
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-06-07 19:01
---
Subject: Bug 40008
Author: jvdelisle
Date: Sun Jun 7 19:00:47 2009
New Revision: 148253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148253
Log:
2009-06-07 Jerry DeLisle
PR li
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-06-07 19:08
---
Subject: Bug 40008
Author: jvdelisle
Date: Sun Jun 7 19:07:46 2009
New Revision: 148255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148255
Log:
2009-06-07 Jerry DeLisle
PR fortr
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:15
---
Subject: Bug 40334
Author: jvdelisle
Date: Tue Jun 9 03:15:04 2009
New Revision: 148303
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148303
Log:
2009-06-08 Jerry DeLisle
PR li
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:18
---
Subject: Bug 40334
Author: jvdelisle
Date: Tue Jun 9 03:18:30 2009
New Revision: 148304
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148304
Log:
2009-06-08 Jerry DeLisle
PR li
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:19
---
Fixed on 4.4 and 4.5
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:21
---
I think we are done with this. Reopen if more suggestions.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-06-10 02:18
---
The two locations referenced by valgrind in transfer.c is in code that is
unchanged from 4.3, so I don't think that is where the problem is. However,
looking at the CP2K code line involved:
WRITE(unit=un
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2009-06-10 03:11
---
I was able to do a regression hunt. Going to r145209 just before the big I/O
patch eliminates the error. I then moved forward to r145636 and confirmed the
breakage.
I then manually removed the use of the
201 - 300 of 3058 matches
Mail list logo
