--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-03-30 01:01
---
*** Bug 36761 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-03-30 01:08
---
See Re: DEALLOCATED array's do not have size zero on comp.lang.fortran for
additional discussion.
http://coding.derkeiler.com/Archive/Fortran/comp.lang.fortran/2009-03/msg00073.html
--
http://gcc.gnu.org
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-03-29 00:30
---
Subject: Bug 39528
Author: jvdelisle
Date: Sun Mar 29 00:30:17 2009
New Revision: 145221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145221
Log:
2009-03-28 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-03-24 12:24
---
Subject: Bug 39528
Author: jvdelisle
Date: Tue Mar 24 12:24:29 2009
New Revision: 145030
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145030
Log:
2009-03-24 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-03-24 12:30
---
Subject: Bug 39528
Author: jvdelisle
Date: Tue Mar 24 12:30:17 2009
New Revision: 145031
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145031
Log:
2009-03-24 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-03-24 12:33
---
Fixed on 4.4.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-03-24 01:15
---
I will give this a shot.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-03-09 02:21
---
I am looking into this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-03-09 03:17
---
This is a variation of pr37834. My patch for it introduced this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-03-09 03:35
---
With the following example:
REAL :: x
CHARACTER(80) :: str
x = 0.0
write (6,'(f0.0)') x
write (6,'(f0.1)') x
write (6,'(f0.2)') x
write (6,'(f0.3)') x
write (6,'(f0.4)') x
END
gfortran gives:
$ gfc
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-03-09 04:55
---
Subject: Bug 39402
Author: jvdelisle
Date: Mon Mar 9 04:54:50 2009
New Revision: 144719
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144719
Log:
2009-03-08 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-03-09 05:00
---
Committed revision 144718. (passed regression testing, had wrong PR number in
ChangeLog, fixed)
Index: write_float.def
===
--- write_float.def
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-03-09 05:07
---
David, thanks for the report. Closing. If anyone feels strongly about
backporting to 4.3, let me know.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-02-23 04:37
---
If anyone is looking into this, please let me know if there are any specific
posix calls needed that I should put into the gfc_posix module. ( Priority
wise.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-02-16 00:59
---
:) Well we are a bit short handed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-02-04 01:55
---
I agree, closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-02-03 04:43
---
I believe gfortran is correct as far as giving an error. The last logical
value does not begin with a T(t) or F(f).
On the commented out case gfortran agrees with g77. The string has one extra
space in it so
--- 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 #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 #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 reject
--- 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 valid
While
--- 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 the internal
--- 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: strlen
--- 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 #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 #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 #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 'e
--- 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=gccview=revrev=143327
Log:
2009-01-12 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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=gccview=revrev=143328
Log:
2009-01-12 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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
--- 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 #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
--- 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 seconds
: 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
ReportedBy: jvdelisle at gcc dot
--- 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 is a regression from 4.3
--- 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=gccview=revrev=143102
Log:
2009-01-05 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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=gccview=revrev=143103
Log:
2009-01-05 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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 #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
--- 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 #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 containing I/O
--- 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=16997action=view)
Patch that splits formatted read and write
This is the patch mentioned in comment 0. This patch touches
--- 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-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 pr38439.f
$ ./a.out
--- 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 #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=gccview=revrev=142884
Log:
2008-12-22 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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
--- 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=gccview=revrev=142889
Log:
2008-12-22 Paul Thomas pa...@gcc.gnu.org
PR
--- 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=gccview=revrev=142890
Log:
2008-12-22 Paul Thomas pa...@gcc.gnu.org
PR
--- 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=gccview=revrev=142898
Log:
2008-12-22 Paul Thomas pa...@gcc.gnu.org
PR
--- 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=gccview=revrev=142899
Log:
2008-12-22 Paul Thomas pa...@gcc.gnu.org
PR
--- 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 #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=gccview=revrev=142870
Log:
2008-12-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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=gccview=revrev=142871
Log:
2008-12-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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=gccview=revrev=142876
Log:
2008-12-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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 #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=16950action=view)
Revised patch
This is latest version of the patch. Please test.
--
http://gcc.gnu.org/bugzilla
--- 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 = high
--- 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
--- 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)') value
--- 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.8)') -0.0001
write(*, '(a,g10.4,a)') ,3.45,
write
--- 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 descriptor
write
--- 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=gccview=revrev=142747
Log:
2008-12-13 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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=gccview=revrev=142748
Log:
2008-12-13 Jerry DeLisle jvdeli...@gcc.gnu.org
--- 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 #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 #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 #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=gccview=revrev=142575
Log:
2008-12-08 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-07 20:20
---
The g77 compiler is no longer supported on any platform. Gfortran will compile
the code and works on linux, so you can get a windows version of gfortran at
http://gcc.gnu.org/wiki/GFortranBinaries and it should
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-07 23:58
---
This has been seen before and until now I thought it was an artifact of
valgrind and that the Front end is suppose to set some values. I will see if
we can fix this.
--
jvdelisle at gcc dot gnu dot org
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-08 00:52
---
After thinking about it some, I think we should accept with -std=legacy since
it is accepted by g77
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
--- 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 #2 from jvdelisle at gcc dot gnu dot org 2008-12-06 18:43
---
On it
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-06 19:35
---
This very well could be the ftruncate issue since I did modify the code path.
however, it seems that if these test cases worked before then we are
unnecessarily doing the ftruncate for the pos= code path
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-06 21:01
---
I did miss an fbuf_flush. I am not sure why it matters unless it is avoiding
some actual disk operations for us. Try this and let me know.
@@ -2146,7 +2155,10 @@ data_transfer_init (st_parameter_dt *dtp
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-06 21:54
---
Subject: Bug 38291
Author: jvdelisle
Date: Sat Dec 6 21:53:11 2008
New Revision: 142528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142528
Log:
2008-12-06 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:12
---
Subject: Bug 38425
Author: jvdelisle
Date: Sun Dec 7 01:10:42 2008
New Revision: 142534
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142534
Log:
2008-12-06 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:17
---
Subject: Bug 38425
Author: jvdelisle
Date: Sun Dec 7 01:15:46 2008
New Revision: 142535
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142535
Log:
2008-12-06 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:18
---
Fixed on trunk:
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-06 04:15
---
Subject: Bug 38291
Author: jvdelisle
Date: Sat Dec 6 04:13:34 2008
New Revision: 142515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142515
Log:
2008-12-05 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-12-06 04:19
---
Subject: Bug 38291
Author: jvdelisle
Date: Sat Dec 6 04:17:31 2008
New Revision: 142516
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142516
Log:
2008-12-05 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-06 04:19
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-06 04:34
---
Closing, I do not consider this a bug for reasons stated in comment #1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
701 - 800 of 3029 matches
Mail list logo
